我正在开发一个大数据库，从这种情况来看，我决定至少考虑两次关于表格和字段布局的决策。 我最关心的是主键。

我几乎总是使用table name plus _id来命名这些索引。 我这样做是因为在连接表时我不必担心重复的字段名称，因为Delphi数据库组件为字段提供了table_name.field_name而只是字段。

另一方面，如果我们可以为每个表使用相同的ID字段名称，那么创建一个函数来处理与该索引控件有关的每个表总是更容易。

有没有人在选择其中一个数据库设计时遇到过错误？ 在每个字段名称上重复表名称是一种好方法吗？

我过去设计了许多数据库，并且错误地不一致地命名表和列。我知道其他人有不同的意见，但这些是我现在遵循的规则：

表名是复数 我觉得有一个products表而不是product表是很自然的，特别是在选择语法时：SELECT whatever FROM products感觉比SELECT whatever FROM product好。最后，如果您选择单数或复数，则无关紧要，只要您不混合它们即可。

字段名称是单数 同样，这是一个或多或少随意的选择，但对我来说似乎很自然，也是大多数人使用的。 (你可以说SELECT descriptions FROM products更有意义，但嘿，你不能争论什么)

所有名称均为小写，并使用下划线分隔单词 有些人使用Pascal样式大小写，例如ProductId甚至JavaScript样式ProductId。我个人曾经使用过许多不同的数据库引擎，说实话，我不能不记得哪些是区分大小写的，哪些不是。 table_name似乎被普遍接受，我从来没有遇到任何问题。由于您专门为Delphi应用程序设计数据库，因此您可能希望选择Pascal样式，以便源代码不会混合使用不同的样式。我个人只是坚持使用field_name。 (顺便说一句：即使某些数据库允许使用标识符中的特殊字符，我也会像瘟疫一样避免使用它们，对于可能是数据库关键字的列名也是如此。即使我为表制造商设计了数据库，我也会永远不要将产品表命名为"表格")

主键和外键包括表名 products表获取product_id主键。无论其他表链接到哪一个都获得product_id外键。这会自动记录数据库设计的一部分，并允许使用自然连接。我之前设计了一个数据库，每个表都有一个标记为"id"的主键。那确实非常混乱。

其他列不会为其表名添加前缀 这可能就是这个列表上的规则我偶尔会打破一次，但首先要做的事情。根据此规则，产品的描述将进入description字段，而不进入product_description。造成这种情况的主要原因是代码中的混乱程度较低。查询变得更短，更易于阅读。 SELECT product_id, description, price FROM products WHERE price>1 AND price比SELECT product_id, product_description, product_price FROM products WHERE product_price>1 AND product_price更容易阅读。两个查询都会做同样的事情，但是一个查询比另一个更多。 有时我违反这条规则有三个原因：

一种。对于主键。请参阅＃4 - 能够看到哪些列是什么不是混乱的主键，但重要的是每次都写下来。

湾当两个完全不同的值类型将共享相同的标识符时：一个人的名称与产品名称完全不同。在开发的某些阶段，它可以更轻松地区分person_name和product_name，而无需交付大量元数据。 (或者，就此而言，在人的name和产品的brand_name之间，这消除了对表前缀的需要。)

C。如果两个包含相同字段名称的表可能经常在查询中连接。如果您有产品的description和订单的description，则可能需要重新命名查询的列，这可能很麻烦。

同样，以上所有都是个人偏好。你的旅费可能会改变。唯一似乎普遍认同的是：选择一种风格并坚持下去。

附：我可能没有回答你的部分问题，但"......创建一个函数来处理与索引控件有关的每个表总是更容易。"对我毫无意义。

我认为这主要是个人喜好和你喜欢的打字数量以及何时打算。将所有字段名称键入为table_name.field_name，这样您就可以在join语句中执行SELECT *而无需在重复的字段名称上使用表名进行资格预审，这似乎是很多字段前几次输入的字段可能需要预先认证，如果你的大多数select语句都包含字段名称，那么只需输入table_name.field_name字段就好像打字一样。

我确信添加更长的字段名称具有无关紧要的性能问题，并且可能只有当架构信息通过网络传输到ODBC但仍然不是真正的问题时才真正引人注意。

我不知道Delphi，但是在.NET中你也可以按位置找到字段名，或者访问被标记为主键字段的字段，所以我不确定一个函数参数是否有效要求表有相同的ID字段名称。

我总是将我的主键字段在我的表中保存为UID，而不是在字段名称声明中包含tablename，除了必须在多个表中预先限定UID字段选择语句之外我从未遇到过任何问题。虽然我可以看到将tablename.UID包含在关键字段中的一些好处，因为跨多个表的很多SELECT *语句都不会有重复的字段错误，除非其他表中有重复的数据(我希望不会)。

还需要考虑的另一件事是数据库建模。诸如ERwin，Visio等工具会自动将父PRIMARY KEY向下迁移到关系中，因此如果该字段在父表中作为前缀，则无需在child1中重命名该字段。由于没有重命名，也没有人会忘记这样做的危险，只要看一下该字段的名称就可以让您自信地看到它来自哪里，而不需要在视觉上遵循与该字段来源的关系。当存在多个关系级别并使ER图表更具可读性时，这一点尤为重要，IMO。

它也让SQL更清晰，因为我的大脑不需要"解析"别名来找出哪个字段来自哪里，并使NATURAL连接的危险性降低2，但其他人可能对此有不同的看法。 。

1如果使用parent.id和child.id，则必须将迁移的密钥重新关联到child.parent_id之类，以避免命名冲突。但是，如果使用parent.parent_id和child.child_id，则无需执行任何操作 - 迁移的密钥将自动命名为child.parent_id。链条继续grandchild.grandchild_id等......

2诚实地说，如果你可以帮助它，你永远不应该做自然 - 总是明确指定你的连接标准。

在delphi中，您也可以使用别名来解决重复名称字段的问题。

看到：

这解决了ClientdataSets对象查询中重复名称的问题。 您的Delphi应用程序使用您在myDesiredName中提供的名称