SQL Server loosely coupled tables - performance considerations?

Question

I am building a database schema for a new application from scratch, and my two goals are loose coupling (scalability) and performance (but performance is the MOST important). I am not sure if it would be a good idea to include foreign key columns in central tables. My question would probably be best understood using an example (please keep in mind that this example is purely hypothetical):

We have a table, let's call this table "Animal". In this table we have several entries which would define properties for various types of "Animal"s stored in the database. We also have another table called "AnimalName", the purpose of which is to store the name of each Animal in the "Animal" table in conjunction with a Language ID (so we have a table which stores the names of each animal in the "Animal" table in each language).

I have two ways of implementing the above tables:

First Way

Animal Table: AnimalID (PK)
AnimalName Table: AnimalNameID (PK), AnimalID (FK), LanguageID (FK), Name

and queries would look like this:

SELECT * FROM Animal a JOIN AnimalName an ON an.AnimalID = a.AnimalID and an.LanguageID = ? WHERE a.AnimalID = ?

Second Way

Animal Table: AnimalID (PK), AnimalNameID (FK)
AnimalName Table: AnimalNameID (PK), LanguageID (FK), Name

and queries would look like this:

SELECT * FROM Animal a JOIN AnimalName an ON an.AnimalNameID = a.AnimalNameID and an.LanguageID = ? WHERE a.AnimalID = ?

For the second way, if I was to add an "AnimalID" FK column to the AnimalName table, then it would support querying expressed in the first way as well.

Which one of the above methods will provide the FASTEST performance (this is crucial!)? Which one of the above methods would you generally recommend from your experience?

Much thanks in advance to all who answer!

Answer 1

Only the first way models correctly the problem you described: an animal has many names, one for each language . The second way models something along the lines of an animal has one name which happens to be in language foo , something completely different from your problem description.

For this kind of query as you described the AnimalNames table must be clustered uniquely by (AnimalId, LanguageId) and have the primary key as a non-clustered constraint, or even better dispose the AnimalLanguageID PK altogether and model a composite PK of (AnimalID, LanguageID) .

Also you must read Designing Indexes

Answer 2

The first way gives you a standard one-to-many relationship between Animals and AnimalName, allowing many names for each Animal, which makes sense.

With the second way, each Animal gets exactly one name, and a single name can be assigned to many animals, which does not make sense.

Answer 3

The second approach is better. AnimalName and Animal will have a 1-to-many relationship, which makes better sense here.