using foreign key as part of primary key

It depends on how the data is organized. For clear top-down hierarchies (company->dept->employee), where the lower levels are specific attributes of the higher ones and would have little or no meaning outside that relational context, inheriting andmigrating PKs is indicated. However, if you have an entity that is conceptually a standalone but composites other entities, creating its own hierarchy using FKs to the other objects is preferable.

For example, an order is for a customer, is taken by an employee and consists of items and prices. Customer and employee are attributes of a particular order, so they're FKs to their respective parents, but the order is identified by its own independent PK. The items in the order are specific tojust that order, so their PK must inherit the order's PK; since the items themselves could be anything in the catalog, they are identified by FK into the catalog.

If you design your relationships, indexes (PK, AK, IE) and RI using the smallest number of relevant attributes you will have excellent performance. Give careful consideration to what you put in each of your tables and how those things relate to others -- too much redundant data or too many indexes for a table are the major performance killers. Take full advantage of RI so your apps don't have to add the burden of doing their own lookups.

I hope I had enough coffee to make this helpful. :-)