命名表和视图时应遵循什么标准？

命名表和视图时应遵循什么标准？例如，将tbl_之类的东西放在表名的开头是个好主意吗？是否应该以ct_，lut_或codes_之类的方式指定代码/查找表？还有其他的做/不做的事情吗？

我使用的是MS SQL Server，并且有许多数据库和许多表，因此最好将我们作为标准并带有一些支持性的理由使用。

好的，首先不要在表名的前面加上tbl。这是一张桌子，我们现在已经知道了。那就是匈牙利符号法，而人们在5年前就停止这样做了。

只需根据对象是什么来调用它即可。如果表包含员工数据，则将其称为“员工”。如果其中包含有关计算机的信息，则将其称为“计算机”。如果将计算机映射到员工，则将其称为“ EmployeeComputer”或“ ComputerEmployee”（我个人更喜欢“ EmployeeComputer”）。

没有使用任何实权命名约定（除了不使用匈牙利表示法以外）。只要对象名称有意义就很重要。

对于权限和分组，我们都使用模式（可能将模式视为SQL中的名称空间）。因此，我们没有“ tbl”等

• 数据事物
• 数据历史
• 资料

没有代码进入数据模式。没有表存在于数据模式之外。当然，如果您愿意，可以扩展为具有“查找”或“登台”模式。

对于我们使用的视图，vw但这是为了将它们与SQL Server 2000中的表区分开来，这现在有点遗留了

我个人是FanöBedingung的忠实拥护者，也就是说在这里，不允许将名称作为另一个有效名称的开头。

其次，两个名字之间的汉明距离远胜于一个不同的字母。

是的，这是前数字时代的规则，但它们使生活更轻松。

当语音识别变为真时，名字必须是可发音的，否则您会发疯。

我不知道实际上有什么“最佳”命名约定，因为它实际上归结为个人喜好和易于开发。我的建议是选择一个命名约定并遵守它。如果希望用下划线分隔单词，请在所有数据库对象中进行分隔。如果希望使用camelCase，请在所有数据库对象中使用。

在我的商店中，我们遵守以下规则：

我们用下划线分隔单词，并使用所有小写字母。
我们的表名描述了它们的含义：dbo.person，dbo.invoice。
我们的多对多表名还描述了它们的含义（增加mm表示映射的多对多关系：dbo.person_mm_address。我们用户定义的存储过程描述了对象和所执行的动作：usp_person_select ，usp_address_select_by_city我们的视图和函数遵循与存储过程相同的规则，我们的索引包括表，键列（按顺序）以及集群/非集群的指示：ix_person_last_name_first_name_nc

仅仅因为这是我们在我的商店中使用的，并不意味着这些规则适合您。选择您和您的开发团队都同意的有用且易于开发的内容，并建立一种了解和使用您决定的命名约定的文化。在我们的案例中，这包括对数据库中创建的所有对象的代码审查。随着时间的流逝，文件化的命名约定和对等代码审查的结合导致与约定的偏离越来越少。

我希望这种“无答案”可以有所帮助。

我对这些很满意

• 表格名称：小写和下划线，单数{customer，product}
• 多对多关系的表名：tablename1_tablename2：{customer_product}
• 视图：将小写字母添加到结尾{customerv，productv，product_groupv}
• 存储过程：表名和函数{customer_select，customer_insert，customer_delete，customer_update}

如果您有便宜的共享托管软件包，则需要在所有对象之前使用项目缩写，例如，数据库管理员站点，da_users，da_questions