在设计数据库时使用表前缀是一个好习惯吗?

时间:2011-05-27 10:16:28

标签: database-design

在设计数据库时使用表前缀是一个好习惯吗?

对于像“ user_detail ”这样的表格 我使用 ud_name ud_email 等列名称。

我这样做是因为我想为每一列(在每个表中)保留唯一的名称,以便以后在加入时不会出现任何冲突列名的问题。

虽然我的一些同事在读取列名时遇到问题(我不知道为什么),并且他们建议Name应该尽可能简单易读,所以我不应该使用任何前缀。

数据库设计遵循的标准命名法是什么?有前缀是不是很糟糕?请通过一些链接支持您的回答。

谢谢你 享受制造:)

5 个答案:

答案 0 :(得分:7)

包括orignial海报在内的几张海报都吹捧了独特专栏名称的好处,好像它是天生的,显而易见的天生的好处。我问:为什么列名中的唯一性会好?四十年前,有大型机数据存储技术需要独特的列名。二十年前,这污染了PC上的dBase设计。由于主导数据存储模型已经成为关系型DBMS,因此没有必要,而且我认为,没有任何理由要求使用唯一的列名称。

有一个被称为“域名完整性”的概念,这意味着如果没有包含表的上下文,列名就没有意义,就像没有其拥有的模式和数据库等的上下文时表名没有意义一样。 / p>

无法引用列而不在SQL中引用其包含的表。如果您认为表名太长而且您不想一直输入它,您可以为选择列表添加别名。

如果使用通过将表名或表名的缩写卡在列名中而产生的唯一列名,这与使用带有点的表名(或缩写别名)而不是您的名称有何不同带下划线的前缀?我认为事实并非如此。不同之处在于强制将父项的指示符强制转换为子项名称只会使该子名称的可读性降低,并且不可避免地会导致更多冗余和不太可读的SQL。

我在SQL Mag论坛的this post中讨论了我首选的命名约定。

最佳名称是最短的自然名称,清楚地描述了它们包含的数据的内容或含义。这些名称可以而且必须在包含它们的对象的上下文中进行。尝试强加唯一性或使用其他约定(如匈牙利化表和列)只会增加混乱,使您的数据库更难以阅读和理解,这反过来又会使您的系统不那么可支持。

答案 1 :(得分:1)

这个问题颇具主观性和争论性......

就个人而言,我倾向于不使用前缀并坚持使用合理的名称。

前缀往往很快就会变得很难写。当它们看似有用时,我发现最好别名表,列或两者,即:

select ud.name as ud_name,
       ud.email as ud_email
from user_detail as ud;

另外,我从来没有在使用ORM的应用程序的上下文中处理/配置数据库前缀,但是,如果有的话,我猜它不是很漂亮。

答案 2 :(得分:1)

这是与整个“匈牙利符号”辩论的类似对话 - http://en.wikipedia.org/wiki/Hungarian_notation

无论您做什么,我都建议您的整个团队使用相同的约定来命名您的数据库实体 - 即使您使用的标准也不同意。

我喜欢http://www.interaktonline.com/support/articles/details/Design+Your+Database-Database+Naming+Convention.html?id_art=24&id_asc=221作为标准。

答案 3 :(得分:0)

最好跟你做的事情一起去

列名如tableprefix_column - reason

  1. 它使列名称唯一,并且您与其他表列名称没有冲突。

  2. 如果你选择像columnname这样的公正名称而不是你需要小心,你需要在编写查询时编写tablename.columnname并且还需要在查询中为该列分配别名比如tablename.columnname as xyzname

答案 4 :(得分:0)

表前缀不是唯一的解决方案,但是当你说数据库中的列名应该是唯一的时候你是对的!我们的标准略有不同,我们使用表名作为后缀(参见下文),但结果是相同的:每列都有一个唯一的名称。对于这种单一性原则,最有价值的论点是视图和报告:当连接多个表时,您肯定会操纵具有类似含义的列,如“描述”,“观察”,“代码”或“数字”。如果在此阶段,您的列具有相同的名称,则必须使用别名重命名它们,从而使您的视图变得混乱且难以理解和维护。

以下是一些示例,其中字段名称是由数据性质(日期,时间,代码,ID)+ 表格描述构建的,事实上每列的面额都是唯一的:

Tbl_Attendance        contains attendance data
    id_Attendance     is the identifier
    id_Person         is the foreign key to Tbl_person.id_Person
    id_Zone           is the foreign key to Tbl_Zone.id_Zone
    dateAttendance    is the attendance date
    timeInAttendance  is the check in time
    timeOutAttendance is the check out time

Tbl_PaySlip           contains informations about Payslips
    id_Payslip        is the identifier
    id_Person         is the foreign key to Tbl_person.id_Person
    id_Company        is the foreign key to Tbl_Company.id_Company
    dateStartPayslip  is the starting date of the payslip
    dateEndPayslip    is the ending date of the payslip
    codePayslip       is the unique code of the payslip, built out from company code, person code, period code