例如,所有用户表都以单词"User"开头:
- User
- UserEvent
- UserPurchase
这种命名约定是自然地将相关表分组的最佳(唯一?)实践吗?
在命名规范方面,我有两点不同于常规做法...
我不喜欢使用前缀来让一些东西在UI中分组。对我来说,表的名称应该是代码易读且有意义的。有很多研究(大多被程序员忽略了)表明,像使用下划线、逻辑名称、消除缩写和消除前缀等这些因素对代码理解和操作速度有非常大的影响。而且,如果你使用前缀来区分表,当一个表被多个领域使用时会怎样——甚至更糟糕的是,它最初只在一个领域中使用,但之后开始在另一个领域中使用。你现在要重新命名表吗?
我几乎完全忽略名称长度。我更关心的是可读性和理解性,而不是输入列或表名称需要多花1/10秒的时间。当你记住了所有浪费的时间都在尝试记住你是否将“number”缩写为“no”、“num”或“nbr”,并且考虑到使用Intellisense,使用更长、更有意义的名称对我来说是显而易见的。
有了这些想法,如果您的UserEvents表与用户相关的事件,那么这个名称就十分合适。在我看来,仅使用“Events”会得到一个不够明确的表名。
希望这可以帮到您!
我认为这取决于您计划如何扩展数据模型。例如,如果您不仅想要拥有用户事件,还想要账户事件或登录事件,并且用户、账户和登录都是不同类型的实体,但它们共享一些事件,则您可能需要一个规范化的数据库模型:
个人而言,我会这样重命名我的表:
我也会避免使用前缀来从按字母顺序排序的列表中获取含义。这通常是不好的数据管理方式。如果表之间有密切关联,那么管理数据模型的软件应该能够建立表之间的关系,而不管表的命名方式如何。
像UserEvents这样的名称应该用于描述每行内容与用户和事件之间关系的表。如果我在一个新的数据库中看到这样的表,我会期望在这个表中看到一个由两个外键组成的主键,一个指向Users表,另一个指向Events表。
如果我看到了不同的东西,我就必须放慢速度,直到我理解设计者的约定为止。
最后一点引发了一些问题:有多少新人需要快速掌握数据库?这些人将有哪些文档可用?这些新人对包括数据库在内的项目的成功或数据库设计师的成功有多重要?
就我个人而言,我更喜欢使用您列出的类似命名条件,因为这是一种非常合乎逻辑的模式,它们以一种易于查找的方式组织在一起,而且通常额外输入的一些字符并不会导致太多问题或时间上的减少。