在数据库表命名规范中是否应该使用前缀的问题是由以下原因引起的：首先，如果选择在应用程序数据库中使用任何需要表的第三方框架组件（例如asp.net会员提供程序），则很少会出现命名冲突的情况。其次，如果为客户开发解决方案，他们可能会限制在单个数据库中存储多个应用程序的数据库对象，特别是如果他们为外部托管付费的情况下。

然而，给表名加前缀的唯一注意事项是一些表可能会被多个应用程序使用，这种情况下，原始前缀会变得误导性。最坏的情况是，App1前缀在App1自身已经消失的情况下仍然存在。

给应用程序名称加前缀没有任何价值。首先，第三方组件不应该与您的应用程序表位于同一个模式/所有者下，以免引起命名冲突。其次，被限制在单个数据库中并不意味着被限制在单个模式中。

我同意。在我发布这个问题的五年时间里，我完全改变了我的想法。如果可以的话，我会删除这个答案。

但是如果我想要将我的表命名为user，这在PostgreSQL中是一个保留字，使用前缀将解决这个冲突。

这两种情况对大多数人来说都是相对边缘的情况（包括我自己）。不加前缀更简洁和整洁。

在数据库表命名规范中使用前缀的原因是为了提高安全性。然而，有人认为任何命名规范都无法改善安全性，因为如果入侵者获得了对数据库的访问权限，他们肯定也有权限列出表名并选择查看其用途。但是，有人认为真正令人困惑的表名可能间接地加剧了安全性问题。这会使进一步的开发变得困难，从而降低了解决安全问题的机会，或者甚至可能隐藏潜在问题。举个例子，如果一个名为'sro235onsg43oij5'的表中充满了具有随机字符串和数字的随机命名的列，新开发人员可能会认为这是随机的测试数据（除非他涉及与之交互的代码），但如果它被命名为'userpasswords'或类似的名称，任何查看表的开发人员可能会震惊地发现密码以明文形式存储。如果入侵者只能进行有限的SQL注入攻击，那么他们很可能无法列出表名。然而，这只是一个相当弱的额外安全措施（实际上不应该用于安全目的）。

解决方法是在数据库表命名中使用前缀。通过在表名中添加前缀，开发人员可以更容易地识别表的用途，从而减少了开发和维护过程中的混淆和错误。这可以提高开发人员对表的理解和正确使用，同时也增加了代码的可读性和可维护性。此外，使用前缀还可以帮助开发人员更轻松地进行数据库查询和操作，提高开发效率。虽然在安全性方面，使用前缀并不能提供绝对的保护，但它可以作为一种额外的安全层，增加入侵者对数据库的攻击难度。

总之，数据库表命名中使用前缀可以提高开发效率和代码可读性，并在一定程度上增加安全性。虽然它并不能解决所有安全问题，但它是一种值得考虑的额外安全措施。

应该在数据库表命名规范中使用前缀吗？

我发现匈牙利式的数据库对象前缀来表示它们的类型相当讨厌。在我工作的地方，每个表名都必须以"tbl"开头。在每种情况下，命名约定最终都会在某人需要进行一个本来是小改动时带来很多困扰。

例如，如果你的约定是表以"tbl"开头，视图以"v"开头，那么当你决定用其他后端对象替换表并提供视图以保持兼容性或作为首选接口时，应该怎么办？我们最终得到了以"tbl"开头的视图。

我认为整个匈牙利概念在今天已经过时了。我认为这只是过去的物品组织方式更困难的遗留问题，有时对象的名称是唯一的区分标志。

我认为只要默认模式未使用或未设置，我可以同意你的观点。当搜索用法时，这变得更加困难，因为可能是'MyTable'、'[dbo].MyTable'、'dbo.MyTable'、'MyDatabase..MyTable'、'MyDatabase..[MyTable]'等等；当同一数据库中其他模式的对象具有相同的名称时，这变得越来越困难。