我们在相关表上放置了通用前缀,以确保它们在我们的数据库管理软件(Toad,Enterprise Manager等)中彼此相邻显示。
因此,例如,所有用户表都以单词User:
开头理想情况下,为了纪念three great virtues of a programmer这些表应分别命名为User,Event,Purchase以节省一些打字,同意吗?
此命名约定是否是将相关表自然分组的最佳(仅?)实践?
答案 0 :(得分:24)
我倾向于在这两个方面违反命名约定......
我不喜欢使用前缀,以便在给定的UI中将事物组合在一起。对我来说,这些表应该被命名为在代码中它们易于阅读并且有意义。有许多研究(大多数被程序员忽略)表明,使用下划线,逻辑名称,消除缩写和消除前缀之类的东西对理解和使用代码的速度都有很大的影响。此外,如果使用前缀来分解表,当多个区域使用表时,您会怎么做 - 或者更糟糕的是,它只在一个区域中开始,但后来开始在另一个区域中使用。你现在需要重命名表吗?
我几乎完全忽略了名字长度。我更关心可读性和可理解性比关于输入列或表名更长1/10秒。当你还记住所有浪费的时间试图记住你是否将“数字”缩写为“no”,“num”或“nbr”并记住使用Intellisense之类的东西,使用更长,更有意义的名字是对我来说毫无疑问。
考虑到这些因素,如果您的UserEvents表确实与用户相关的事件有关,那么该名称就非常有意义了。仅使用事件最终会给你一个差的命名表,因为我认为这个名称不够清晰。
希望这有帮助!
答案 1 :(得分:6)
我不会将命名约定用于按字母顺序排列表名。它以这种方式运行时很好,但这不应该是设计的。
阅读Joe Celko的书“SQL Programming Style”。他在该书的第一章是关于命名约定,由ISO 11179元数据命名标准指导。他的一个建议是避免在命名约定中使用不必要的前缀。
答案 2 :(得分:4)
如果此表是“User”和“Event”表之间多对多关系的表示,我会使用这种表示法,即“UserEvent”。
答案 3 :(得分:3)
我认为这取决于您计划如何/如何扩展数据模型。例如,如果您决定不仅要拥有用户事件,还有帐户事件或登录事件,用户,帐户和登录都是不同类型的实体,但它们共享一些事件。在这种情况下,您可能需要规范化的数据库模型:
答案 4 :(得分:3)
我猜SQL中的命名约定或者至少应该遵循与其他编程语言中使用的相同的指导原则。我总是喜欢变量名称/类名,它们清楚地标明了目的,通常意味着更多的输入。我认为要记住的重要事情是代码只写一次但是读了很多遍,所以清晰度至关重要。 过去4或5年我注意到变量名称已从“eDS”增长到“employeeDataSet”,我认为IntelliSense是其中的主要原因。 我认为我们将在SQL中看到同样的事情,因为Red Gate SQL Prompt和现在的MS SQL2008已经将Intellisense引入了mainstrem数据库世界。
答案 5 :(得分:1)
我也会避免使用前缀来获得字母顺序列表中的含义。通过这种方式使用名称通常是糟糕的数据管理。如果表密切相关,那么管理数据模型的软件应该能够建模表之间的关系,无论表的命名方式如何。
当每行的内容描述用户和事件之间的关系时,应使用类似UserEvents的名称。如果我在数据库中看到这样一个对我不熟悉的表,我希望在这个表中看到一个由两个外键组成的主键,一个用于Users表,一个用于Events表。
如果我看到不同的东西,我必须放慢速度,直到我理解设计师的惯例。
最后一点提出了一些问题:许多新人将加入数据库?这些人有哪些文件?这些新人对项目的成功有多重要,包括数据库,还是数据库设计师的成功?
答案 6 :(得分:0)
我个人赞成命名条件类似于你在那里列出的条件,因为它是一个非常合乎逻辑的模式,它们以一种你可以轻松找到它们的方式组织,总体而言,额外的输入位通常不会导致很多问题或减少时间。
答案 7 :(得分:0)
就个人而言,我这样重命名我的表: