表列的命名约定？你怎么做呢？

Question

他们在您的专业经验中的时刻是否会脱离严格的命名约定结构（如建议的here），或者在其他堆栈溢出问题中讨论的前缀命名约定。

如图所示，更简化。在这个简化的描述狗，人，以及一个人拥有什么类型的狗的关系。关系表使用的列名称可以按照一种方式进行排序，以便立即全面地解释其生成的操作。

现在，正如着名的编程格言“依赖于它”。我希望情况确实如此，但我希望听到来自该领域的专业人士的意见，如果推动一些双方同意的坚定不移的标准，无论项目范围大小如何，都应该足够，全面。

Answer 1

在关系表中，我认为通过这些列名对关系施加意义是不好的形式。相反，我认为最好包括一个ROLE列来识别项目之间的关系。

例如，角色可能是OWNS，或者角色可能是WALKS，或角色可能是GROOMS。此外，在这些关系中包含日期的良好做法。因此，通过简单的更改（添加角色和一些日期），此表现在是静态的，并且用途是数据驱动的，不受列名称的阻碍。

这个基本模型几乎可以用于任何关系，因此是一个很好的模式。它也是像Semantic Ontologies这样的新数据管理习语的驱动隐喻，你希望ROLE在三元组中扮演谓词。

我的2美分：）

Answer 2

我一般会说这是一个糟糕的主意。你会让那些不易理解this_person_id = id_person或者owns_dog_type_id = id_dog_type的开发人员因此可以创建一个管理问题，但我认为这比id_person = id_person和id_dog_type = id_dog_type更容易理解。

什么是SQL反模式，并且您不应该使用，是每个表中的初始ID的ID。它可以在开发长期复杂的查询和报告问题时产生错误，并且通常是一个糟糕的想法。在允许自然连接的数据库中，这是一个更糟糕的选择，因为您可能最终将id inteh people表连接到pets表中的id