2010-07-25 111 views
8

我不完全确定是否有行业标准或其他方面的标准,所以我在这里问。Sql命名最佳实践

我命名用户表,我并不完全确定如何命名成员。

user_id是一个明显的问题,但我想知道是否应该用“user_”或其他字段加前缀。

USER_NAME user_age

或只是名字和年龄,等...

回答

9

这样的前缀是毫无意义的,除非你有更多的任意东西;像两个地址。然后,您可以使用address_1,address_2,address_home等

与电话号码相同。

但对于像年龄,性别,用户名等静态的东西;我会像这样离开他们。

只是为了显示你 如果你是前缀的所有这些领域,你的查询可能看起来像这样

SELECT users.user_id FROM users WHERE users.user_name = "Jim" 

当它很容易被

SELECT id FROM users WHERE username = "Jim" 
+2

+1:对于大多数人来说,带着扭曲。对于ID(比如user_id),我们总是拼出全名,对于其他所有我们不预先指定表名的文件。使连接更容易阅读。 – NotMe 2011-10-25 18:06:39

+1

“性别......我只会让他们这样” - 更可能是“性别”(特别是男性和女性),其中有一个行业标准代码[ISO 5218](http://en.wikipedia。 org/wiki/ISO_5218),而不是性别(男性,女性和其他)。 – onedaywhen 2011-10-26 08:31:17

2

只是名字和年龄去,这个表应该提供必要的情况下,当你想知道什么样的名字你”重新工作。

2

把它看作一个实体和名称字段相应

我建议一个用户表,与字段,如ID,姓名,年龄等

A组记录是一群用户,但是字段组代表一个用户。因此,您最后提到user.id,user.name,user.age(尽管您不总是包含表名称,具体取决于查询)。因此,您最终提到user.id,user.name,user.age(尽管您不总是包含表名称,具体取决于查询)。

2

对于表名,我通常使用复数名词(或名词短语),就像你一样。

对于列名我不会使用表名作为前缀。该表本身指定了该列的上下文。

0

这是个人偏好。我们可以给你的最好建议是一致性,易读性,并确保关系正确命名。

使用有意义的名称,如果可能的话,不要缩写,除非您使用的存储机制不适用于它们。

在关系中,我喜欢在主键上使用Id,在外键上使用[table_name] _Id。例如。 Order.Id和OrderItem。OrderId

如果使用代理键作为主键,则Id可以很好地工作。

此外,您的存储机制可能会也可能不区分大小写,因此请务必考虑到这一点。

编辑:另外,thre是一些理论,建议该表应该是该表中的单个记录应表示的名称。因此,表名“用户”而不是“用户” - 个人复数对我来说更有意义,只是保持一致。

6

我同意其他答案,建议不要在表名前加上属性。

不过,我支持使用名称匹配的外键和主键的想法,他们引用,而要做到这一点,你会通常有相关表的前缀id属性。

东西是不是很出名的是,SQL支持使用USING关键字简明接合语法:

CREATE TABLE users (user_id int, first_name varchar(50), last_name varchar(50)); 
CREATE TABLE sales (sale_id int, purchase_date datetime, user_id int); 

然后以下查询:

SELECT s.*, u.last_name FROM sales s JOIN users u USING (user_id); 

相当于更详细和流行加入语法:

SELECT s.*, u.last_name FROM sales s JOIN users u ON (u.user_id = s.user_id); 

这并非总是可行。一个典型示例是users表中的user_id字段,以及引用表中的reported_byassigned_to字段,这两个字段均引用users表。在这种情况下使用user_id字段既不明确也不可能用于其中一个字段。

+0

虽然我没有看到名为“reported_by”和“assigned_to”的列出现问题,但是如果您想更明确地指出它们引用的列,则可以将它们称为“reported_by_user_id”和“assigned_to_user_id”。 – ObiWanKenobi 2010-07-25 07:31:52

+0

@Obi:是的,但我的观点是,在这种情况下仍然不可能使用USING语法。 – 2010-07-25 07:34:44

0

首先,我会建议使用的单数名词,即用户的代替用户,虽然这更多的是一种个人喜好。

其次,也有一些谁愿意总是名称,而不是USER_ID(即表名+编号)主键列ID,以及与替代例如employee_name相似。我认为这是由于以下原因,一个坏主意:

-- when every table has an "id" (or "name") column, you get duplicate column names in the output: 
select e.id, e.name, d.id, d.name 
from employee e, department d 
where e.department_id = d.id 

-- to avoid this, you need to specify column aliases every time you query: 
select e.id employee_id, e.name employee_name, d.id department_id, d.name department_name 
from employee e, department d 
where e.department_id = d.id 

-- if the column name includes the table, there are no conflicts, and the join condition is very clear 
select e.employee_id, e.employee_name, d.department_id, d.department_name 
from employee e, department d 
where e.department_id = d.department_id 

我不是说你应该包括在表中的每一列的表名,但这样做的关键(ID)列和其它“通用“列,如名称,说明,备注等,这些列可能包含在查询中。

3

正如其他答案所暗示的那样,这是个人偏好 - 选择某个命名模式并坚持。
十多年前我曾与Oracle的设计,它使用命名方案,我喜欢,从那时起使用:

  • 表名是复数 - 用户
  • 代理主键被命名为奇异表名的加'_id' - 表USERS的主键是“USER_ID”。这样,当您使用“USER_ID”字段作为外键的其它表
  • 列名不具有表名作为前缀,你有一致的命名。

可选:

  • 与大量表的数据库(译“大”,你认为合适),使用2-3 字符表前缀,这样就可以在逻辑上划分的地区表。例如:包含销售数据(发票,发票项目,文章)的所有表都具有前缀“INV_”,所有包含人力资源数据的表都具有前缀“HR_”。这样一来,查找和排序包含相关数据的表更容易(这也可以通过将表放置在不同的方案中并设置适当的访问权限来完成,但是当您需要在一台服务器上创建多个数据库时,这会变得复杂)

再次,选择你喜欢的命名架构并保持一致。

1

表用户(复数):

  • ID
  • 年龄

简单明了。

+0

同意。除了'id'或'user_id'是一个讨论的话题。因为如果你有很多连接的查询,并且每个表都有'ID'列 - 你很容易被混淆。 – abatishchev 2010-07-25 10:42:04

+1

@abatishchev正如单数对复数。许多数据建模者会说它应该是单数的,因为字段集合代表了一个实体。也就是说,用户记录表中的1行代表什么?它代表1个用户。 – 2010-07-25 16:08:43

+0

@George Marian:是和表代表所有用户 – abatishchev 2010-07-25 16:38:44

0

我明确地使用了相关表

i.e. table = USERS, column name = user_id, user_name, user_address_street, etc. 

在此之前,前缀命名我的专栏,当我开始使用连接,我不得不别名屁滚尿流的列名,以避免在查询冲突结果,然后当从MVC视图中的模板进行访问时,如果查询结果字段名称与发布的数据库模式不匹配,则模板设计人员将会感到困惑,并且必须要求SQL VIEW确定正确的字段名称以使用。

因此,在列名中使用前缀看起来很乱,但实际上它对我们来说效果更好。

0

我想表和列名必须是这样。

表名:
用户 - >为每个字,而不是多个。

列名称:
标识 - >如果我看到 “ID” 据我所知,这是PK列。
GroupId - >我知道有一个名为Group的表,这个列是Group表的关系列。
名称 - >如果在用户表中有名为“Name”的列,则表示用户名。它很清楚。

特别是如果你使用的是实体框架,我想这更多。

注意:对不起,我的英语不好。如果有人会纠正我的坏英语,我会很高兴。