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

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

它是否提供任何安全性(对于可能的入侵者至少还有一个障碍)？我认为用前缀命名它们通常会更舒服,以防我们在代码中使用表名,所以不要将它们与变量,属性等混淆.但我想阅读更有经验的开发人员的意见.

1> Dustin..：

---

我发现匈牙利数据库对象前缀表明它们的类型相当烦人.

我曾在每个表名必须以"tbl"开头的地方工作过.在每种情况下,当某人需要进行其他微小的改变时,命名约定最终会导致很多痛苦.

例如,如果你的约定是表以"tbl"开头而视图以"v"开头,那么当你决定用后端的其他东西替换表并提供兼容性视图时,做什么是正确的.即使作为首选界面？我们最终得到了以"tbl"开头的观点.

---

无论如何,我发现整个匈牙利概念今天过时了.我认为,从组织事物变得困难的日子开始,只剩下一个对象的名称是唯一的区别标记.

2> Ian Nelson..：

---

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

这有助于产生两种可能出现的情况:

如果您选择使用任何需要应用程序数据库中的表的第三方框架组件(例如,asp net membership提供程序),则不太可能发生命名冲突.

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

---

前缀应用程序名称不会添加任何值.1.第三方组件不应与app表在同一模式/所有者下进行,从而导致命名冲突.2.限于单个数据库并不仅限于单个模式.

---

关于为表名加上前缀的唯一警告是，某些表可能最终会被多个应用程序使用，在这种情况下，原始前缀会产生误导。在最坏的情况下，App1前缀会在do1本身消失之后很长一段时间。

3> Stein G. Str..：

---

我没有看到任何命名约定如何提高安全性......

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

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

如果名为(例如)'sro235onsg43oij5'的表中充满了随机命名的coloumns,其中包含随机字符串和数字,新开发人员可能会认为它是随机测试数据(除非他触摸与之交互的代码),但如果它被命名'userpasswords'或类似的任何开发人员如果查看该表,可能会对密码存储在纯文本中感到震惊.