0

我正在从头开始为新应用程序构建数据库模式，我的两个目标是松散耦合（可扩展性）和性能（但性能是最重要的）。我不确定在中央表中包含外键列是否是个好主意。使用示例可能会最好地理解我的问题（请记住，此示例纯属假设）：

我们有一张桌子，我们称这张桌子为“动物”。在这个表中，我们有几个条目，它们将为存储在数据库中的各种类型的“动物”定义属性。我们还有另一个名为“AnimalName”的表，其目的是将每个动物的名称与语言 ID 一起存储在“动物”表中（因此我们有一个表，将每个动物的名称存储在“每种语言的动物”表）。

我有两种实现上述表格的方法：

第一种方式

Animal 表：AnimalID (PK)
AnimalName 表：AnimalNameID (PK)、AnimalID (FK)、LanguageID (FK)、Name

查询看起来像这样：

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

第二种方式

Animal 表：AnimalID (PK)、AnimalNameID (FK)
AnimalName 表：AnimalNameID (PK)、LanguageID (FK)、Name

查询看起来像这样：

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

对于第二种方式，如果我要在 AnimalName 表中添加一个“AnimalID”FK 列，那么它也将支持第一种方式表示的查询。

以上哪一种方法将提供最快的性能（这是至关重要的！）？根据您的经验，您通常会推荐上述哪种方法？

非常感谢所有回答的人！

4

3 回答 3

4

只有第一种方法可以正确地模拟您描述的问题：一种动物有很多名字，每种语言都有一个。第二种方式模仿动物的方式有一个名称，恰好是语言 foo，与您的问题描述完全不同。

对于您所描述的这种查询，AnimalNames 表必须唯一地聚集在一起，(AnimalId, LanguageId)并将主键作为非聚集约束，或者甚至更好地AnimalLanguageID完全处理 PK 并为(AnimalID, LanguageID).

您还必须阅读设计索引

于 2012-05-27T08:50:36.823 回答
2

第一种方法在 Animals 和 AnimalName 之间提供标准的一对多关系，允许每个 Animal 有多个名称，这是有道理的。

第二种方式，每个Animal只得到一个名字，一个名字可以分配给许多动物，这是没有意义的。

于 2012-05-27T05:24:40.253 回答
1

第二种方法更好。AnimalName 和 Animal 将具有一对多的关系，这在这里更有意义。

于 2012-05-27T05:19:44.940 回答