每当我设计数据库时,我总是想知道是否有一种最好的方法来命名数据库中的项目。我经常问自己以下问题:
表名应该是复数吗? 列名应该是单数吗? 我应该为表或列添加前缀吗? 我应该在命名项目时使用大小写吗?
是否有推荐的指导原则来命名数据库中的项?
每当我设计数据库时,我总是想知道是否有一种最好的方法来命名数据库中的项目。我经常问自己以下问题:
表名应该是复数吗? 列名应该是单数吗? 我应该为表或列添加前缀吗? 我应该在命名项目时使用大小写吗?
是否有推荐的指导原则来命名数据库中的项?
当前回答
表名:它应该是单数,因为它是一个表示真实世界对象的单数实体,而不是表示对象的单数实体。
列名:它应该是单数,只有这样它才表示它将持有一个原子值,并将确认归一化理论。然而,如果有n个相同类型的属性,那么它们应该以1,2,…作为后缀。n,等等。
表/列前缀:这是一个巨大的主题,将在后面讨论。
外壳:应该是驼色的
我的朋友Patrick Karcher,我请求你不要写任何可能冒犯别人的东西,就像你写的那样,“此外,外键必须在不同的表中一致命名。如果有人不这样做,殴打他应该是合法的。”我从来没有犯过这样的错误,我的朋友帕特里克,但我写一般。如果他们一起打算为此揍你呢?:)
其他回答
我建议你看看微软的SQL Server样本数据库: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks
AdventureWorks示例使用了非常清晰和一致的命名约定,它使用模式名组织数据库对象。
表的单数名称 列的单数名称 表前缀的架构名称(例如:SchemeName.TableName) 帕斯卡壳(又称上驼峰壳)
--Example SQL
CREATE TABLE D001_Students
(
StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);
CREATE INDEX idxD001_STID on D001_Students;
CREATE TABLE D002_Classes
(
ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
CONSTRAINT fkD001_STID FOREIGN KEY(StudentID)
REFERENCES D001_Students(StudentID)
);
CREATE INDEX idxD002_CLID on D002_Classes;
CREATE VIEW V001_StudentClasses
(
SELECT
D001.ChristianName,
D001.Surname,
D002.ClassName
FROM
D001_Students D001
INNER JOIN
D002_Classes D002
ON
D001.StudentID = D002.StudentID
);
这些是我学到的惯例,但是您应该适应您的开发软管使用的任何东西。
复数。它是实体的集合。 是的。属性是一个实体的单一属性的表示。 是的,前缀表名允许轻松跟踪所有约束索引和表别名的命名。 表和列名用大小写,索引和约束用前缀+ ALL大写。
命名约定允许开发团队在项目的核心设计可发现性和可维护性。
一个好的命名约定需要时间来发展,但一旦它到位,它就可以让团队使用一种共同的语言向前发展。好的命名约定会随着项目的发展而有机地发展。好的命名约定可以很容易地处理软件生命周期中最长和最重要的阶段(生产中的服务管理)中的变化。
以下是我的回答:
是的,当表名指的是一组交易、证券或交易对手时,表名应该是复数。 是的。 是的。SQL表前缀为tb_,视图前缀为vw_,存储过程前缀为usp_,触发器前缀为tg_,后面加数据库名。 列名应以小写字母用下划线分隔。
命名很难,但在每个组织中都有人可以命名事物,在每个软件团队中都应该有人负责命名标准,并确保像sec_id、sec_value和security_id这样的命名问题在融入项目之前尽早得到解决。
那么,一个好的命名规范和标准的基本原则是什么呢
使用你客户的语言 解域 是描述性的 是一致的 消除歧义,反思和重构 不要使用缩写,除非它们 每个人都清楚 不要使用SQL保留关键字作为 列名
基本数据库命名约定(和样式)(点击这里查看更详细的描述)
表名 选择简短、明确的名字,不要超过一两个单词 容易区分表 方便唯一字段名的命名以及查找和链接表 给表取单数名,而不是复数名(更新:我仍然同意这种惯例的原因,但大多数人真的喜欢复数表名,所以我的立场软化了)…请点击上面的链接
虽然很晚了,但我仍然想对列前缀发表我的意见
对于使用table_column(或tableColumn)列命名标准,似乎有两个主要的论据,都是基于列名本身在整个数据库中是唯一的这一事实:
1)你不需要一直在你的查询中指定表名和/或列别名
2)你可以很容易地在整个代码中搜索列名
我认为这两种观点都有缺陷。不使用前缀解决这两个问题很简单。以下是我的建议:
在SQL中始终使用表名。例如,总是用table。列而不是列。
它显然解决了2)你现在只需要搜索表。而不是table_column。
But I can hear you scream, how does it solve 1)? It was exactly about avoiding this. Yes, it was, but the solution was horribly flawed. Why? Well, the prefix solution boils down to: To avoid having to specify table.column when there's ambiguity, you name all your columns table_column! But this means you will from now on ALWAYS have to write the column name every time you specify a column. But if you have to do that anyways, what's the benefit over always explicitly writing table.column? Exactly, there is no benefit, it's the exact same number of characters to type.
编辑:是的,我知道用前缀命名列可以强制使用正确的用法,而我的方法依赖于程序员