每当我设计数据库时,我总是想知道是否有一种最好的方法来命名数据库中的项目。我经常问自己以下问题:

表名应该是复数吗? 列名应该是单数吗? 我应该为表或列添加前缀吗? 我应该在命名项目时使用大小写吗?

是否有推荐的指导原则来命名数据库中的项?


当前回答

表名一定要保持单数,person而不是people 我也一样 不。我见过一些糟糕的前缀,以至于声明我们处理的是一个表(tbl_)或一个用户存储过程(usp_)。后面跟着数据库名…不要这样做! 是的。我倾向于PascalCase我所有的表名

其他回答

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

在我看来:

表名应该是复数形式。 列名应该是单数。 不。 对于表名和列名,可以选择CamelCase(我的首选)或underscore_separated。

然而,就像上面提到的,任何约定都比没有约定好。无论您选择如何做,都要记录它,以便将来的修改遵循相同的约定。


--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大写。

我们的偏好:

Should table names be plural? Never. The arguments for it being a collection make sense, but you never know what the table is going to contain (0,1 or many items). Plural rules make the naming unnecessarily complicated. 1 House, 2 houses, mouse vs mice, person vs people, and we haven't even looked at any other languages. Update person set property = 'value' acts on each person in the table. Select * from person where person.name = 'Greg' returns a collection/rowset of person rows. Should column names be singular? Usually, yes, except where you are breaking normalisation rules. Should I prefix tables or columns? Mostly a platform preference. We prefer to prefix columns with the table name. We don't prefix tables, but we do prefix views (v_) and stored_procedures (sp_ or f_ (function)). That helps people who want to try to upday v_person.age which is actually a calculated field in a view (which can't be UPDATEd anyway). It is also a great way to avoid keyword collision (delivery.from breaks, but delivery_from does not). It does make the code more verbose, but often aids in readability. bob = new person() bob.person_name = 'Bob' bob.person_dob = '1958-12-21' ... is very readable and explicit. This can get out of hand though: customer.customer_customer_type_id indicates a relationship between customer and the customer_type table, indicates the primary key on the customer_type table (customer_type_id) and if you ever see 'customer_customer_type_id' whilst debugging a query, you know instantly where it is from (customer table). or where you have a M-M relationship between customer_type and customer_category (only certain types are available to certain categories) customer_category_customer_type_id ... is a little (!) on the long side. Should I use any case in naming items? Yes - lower case :), with underscores. These are very readable and cross platform. Together with 3 above it also makes sense. Most of these are preferences though. - As long as you are consistent, it should be predictable for anyone that has to read it.

我也支持ISO/IEC 11179风格的命名约定,指出它们是指导方针而不是规定。

参见维基百科上的数据元素名称:

表是实体的集合,并遵循集合命名准则。理想情况下,使用一个集合名称。、人员。复数形式也是正确的:Employees。不正确的名称包括:Employee、tblEmployee和EmployeeTable。”

与往常一样,规则也有例外,例如,一个总是只有一行的表可能用一个奇异的名字更好,例如配置表。一致性是最重要的:检查你的购物是否有惯例,如果有,就遵守它;如果你不喜欢它,那就做一个商业案例来改变它,而不是做一个独行侠。