我们应该在数据库表命名约定中使用前缀吗？

Question

我们正在工作中的开发团队决定表、列、过程等的命名约定。 单复数表命名已经决定，我们使用单数。 我们正在讨论是否为每个表名使用前缀。 我想阅读有关是否使用前缀以及原因的建议。

它是否提供任何安全性（至少为可能的入侵者多了一个障碍）？ 我认为用前缀命名它们通常更舒服，以防我们在代码中使用表的名称，这样就不会将它们与变量、属性等混淆。但我想阅读更有经验的开发人员的意见。

Answer 1

我发现匈牙利数据库对象前缀来指示其类型相当烦人。

我曾在每个表名都必须以“tbl”开头的地方工作过。 在每种情况下，当有人需要进行较小的更改时，命名约定最终都会造成很大的痛苦。

例如，如果您的约定是表以“tbl”开头，视图以“v”开头，那么当您决定用后端的其他一些东西替换表并提供兼容性或视图时，正确的做法是什么？即使作为首选界面？ 我们最终得到了以“tbl”开头的视图。

Answer 2

我更喜欢使用应用程序或解决方案的短名称作为表和其他数据库对象的前缀。

这有助于解决两种可能出现的情况：

1. 如果您选择使用任何需要应用程序数据库中的表的第三方框架组件（例如 asp net 会员提供程序），则不太可能出现命名冲突。

2. 如果您正在为客户开发解决方案，他们可能仅限于单个数据库（特别是如果他们支付外部托管费用），要求他们将多个应用程序的数据库对象存储在单个数据库中。

Answer 3

我不明白任何命名约定如何提高安全性......

如果入侵者有权访问数据库（具有有害权限），他们肯定有权列出表名并选择查看它们的用途。

但我认为真正令人困惑的表名可能会间接恶化安全性。
这将使进一步的开发变得困难，从而减少安全问题得到解决的机会，甚至可能隐藏潜在的问题：

如果一个名为（例如）“sro235onsg43oij5”的表充满了带有随机字符串和数字的随机命名列，则一个新的开发人员可能只是认为它是随机测试数据（除非他接触了与之交互的代码），但如果它被命名为“userpasswords”或类似名称，任何查看该表的开发人员可能都会对密码以明文形式存储感到震惊。

Answer 4

为什么不根据您现有的编码指南来命名表呢？ 将表名视为“类”，将列视为“属性”或“字段”。 当使用可以从类/成员命名自动推断表/列命名的 ORM 时，这会有所帮助。

例如，Castle ActiveRecord，声明如下假设名称与他们所在的成员相同。

[ActiveRecord]
public class Person
{
    [PrimaryKey]
    public Int32 Id { get; set; }

    [Property]
    public String Name { get; set; }
}

Answer 5

如果您使用 SqlServer，好的开始是查看提供的示例数据库以获得一些指导。

Answer 6

过去，我一直反对在表名和列名中使用前缀。 然而，当面临重新设计系统的任务时，拥有前缀对于执行搜索和替换非常有价值。 例如，grep 查找“tbl_product”可能会比 grep 查找“product”提供更相关的结果。

Answer 7

如果您担心混淆表名称，请在代码中使用匈牙利表示法样式系统。 也许“s”代表字符串+“tn”代表表名：

 stnUsers = 'users';
 stnPosts = 'posts';

当然，前缀由您决定，具体取决于您喜欢代码的详细程度... strtblUsers，strtblnmeUsers，thisisthenameofatableyouguysUsers...

在表名中添加前缀确实有一些好处，特别是如果您不将该前缀硬编码到系统中，并允许它在每次安装时进行更改。 首先，正如 Ian 所说，您与其他组件发生冲突的风险较小，其次，如果您愿意，您可以让程序的两个或多个实例在同一个数据库上运行。