我已经看到tbl_前缀装饰了我使用过的最后两个代码库中的所有表格。我想不出任何他们对应用程序开发人员或数据库管理员有用的原因。tbl_Product，tbl_Order命名约定的目的是什么？
如果DBA需要查看哪些对象是表，那么他们总是可以加入DMV或主权利模式表中？我无法想象它们对程序员有什么用处，如果项目使用的是ORM工具，那更是如此。
甚至在编写存储过程时，他们似乎也挡道了。
任何人都可以解释他们如何在非主观方面有用吗？ Ex（有tbl_帮助我执行x任务）
我一遍又一遍地听到同样的原因，这有助于他们知道对象的类型。
在查询中，使用前缀可以帮助他们将表与视图分开，例如。
我真的不同意这一点。在习惯数据库模式之后，前缀变得多余，并且在冗余的情况下，它可能会变得不同步，或者使更改变得更难。
假设您有一张表格，无论出于何种原因，您必须将其分成两个表格。 假设您决定创建一个模拟原始表的视图，从两个新表中选择数据。
你打算重新命名整个代码库还是要坚持前缀为tbl_的视图？
所以我的观点是数据库对象的名称应该而不是有任何前缀来推断它们的类型。
我想不到很多好处。你绝对可以看到更干净的SQL，如下所示：
select post.id, post.subject, post.body from tbl_post post where post.author="eric"
使变量变得更简单。否则，这看起来就像你一直在和在MS Access上学习数据库的人打交道。
这是hungarian notation，或者更确切地说是滥用它。最初的用法是将变量的使用作为前缀的一些重要方面。桌子是桌子这一事实并不是使用匈牙利符号的有用方法。
在ASP匈牙利符号用于指定数据类型，因为VBSCript只有变量。我见过ASP程序员也将它应用于数据库中的表和字段，这是误用的一种方式。
它的一个好处是你可以区分视图，表格和物化视图。当然，当你编写代码时，这并不重要，而是保持它的重要性。如果有人意识到他们正在从视图中拉扯，他们可能会更好地优化代码。基于视图的视图视图可能效率很低。如果没有tbl_或view_前缀，可能更难判断这是否发生。
我认为使用ORM如Entiry框架时，它可以更容易地告诉映射是处理表哪边和哪边是处理对象（实体）。例如，我的tbl_Employee映射到Employee。没有办法让混乱层层的抽象。