每当我设计数据库时,我总是想知道是否有一种最好的方法来命名数据库中的项目。我经常问自己以下问题:
表名应该是复数吗? 列名应该是单数吗? 我应该为表或列添加前缀吗? 我应该在命名项目时使用大小写吗?
是否有推荐的指导原则来命名数据库中的项?
每当我设计数据库时,我总是想知道是否有一种最好的方法来命名数据库中的项目。我经常问自己以下问题:
表名应该是复数吗? 列名应该是单数吗? 我应该为表或列添加前缀吗? 我应该在命名项目时使用大小写吗?
是否有推荐的指导原则来命名数据库中的项?
当前回答
我建议你看看微软的SQL Server样本数据库: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks
AdventureWorks示例使用了非常清晰和一致的命名约定,它使用模式名组织数据库对象。
表的单数名称 列的单数名称 表前缀的架构名称(例如:SchemeName.TableName) 帕斯卡壳(又称上驼峰壳)
其他回答
命名约定允许开发团队在项目的核心设计可发现性和可维护性。
一个好的命名约定需要时间来发展,但一旦它到位,它就可以让团队使用一种共同的语言向前发展。好的命名约定会随着项目的发展而有机地发展。好的命名约定可以很容易地处理软件生命周期中最长和最重要的阶段(生产中的服务管理)中的变化。
以下是我的回答:
是的,当表名指的是一组交易、证券或交易对手时,表名应该是复数。 是的。 是的。SQL表前缀为tb_,视图前缀为vw_,存储过程前缀为usp_,触发器前缀为tg_,后面加数据库名。 列名应以小写字母用下划线分隔。
命名很难,但在每个组织中都有人可以命名事物,在每个软件团队中都应该有人负责命名标准,并确保像sec_id、sec_value和security_id这样的命名问题在融入项目之前尽早得到解决。
那么,一个好的命名规范和标准的基本原则是什么呢
使用你客户的语言 解域 是描述性的 是一致的 消除歧义,反思和重构 不要使用缩写,除非它们 每个人都清楚 不要使用SQL保留关键字作为 列名
不。表应该以它所代表的实体命名。 Person,而不是persons是指记录所代表的人。 同样的事情。列FirstName真的不应该被称为FirstNames。这完全取决于你想用列表示什么。 不。 是的。为清晰起见。如果你需要像“FirstName”这样的列,大小写会让它更容易阅读。
好的。这是我的0.02美元
好吧,既然我们有意见:
我认为表名应该是复数。表是实体的集合(表)。每一行表示一个实体,表表示集合。因此,我将Person实体表称为People(或Persons,随您喜欢)。
对于那些喜欢在查询中看到单一“实体名称”的人来说,这就是我使用表别名的原因:
SELECT person.Name
FROM People person
有点像LINQ的“from person in people select person. name”。
至于2、3和4,我同意@Lars的观点。
请参阅ISO 11179-5:命名和识别原则 你可以在这里获得:http://metadata-standards.org/11179/#11179-5
我之前写过一篇博文:ISO-11179命名约定
我认为这些问题的最佳答案将由您和您的团队给出。有一个命名约定比命名约定的具体方式重要得多。
因为这个问题没有正确答案,你应该花点时间(但不要太多)选择你自己的习惯——这是重要的部分——坚持它。
当然,寻求一些关于标准的信息是很好的,这就是你要问的,但不要因为你可能得到的不同答案的数量而焦虑或担心:选择一个对你来说更好的答案。
以防万一,以下是我的答案:
是的。表是一组记录,老师或演员,所以…复数。 是的。 我不用它们。 我经常使用的数据库——Firebird——所有内容都是大写的,所以没关系。不管怎样,当我在编程时,我以一种更容易阅读的方式写名字,比如releaseYear。