在设计表时,我养成了一个习惯,即有一个唯一的列,并将其作为主键。这可以通过三种方式实现,具体取决于需求:

自动递增的标识整数列。 唯一标识符(GUID) 短字符(x)或整数(或其他相对较小的数字类型)列,可作为行标识符列

数字3将用于相当小的查找,主要是读取表,这些表可能有一个唯一的静态长度字符串代码,或一个数值,如年或其他数字。

在大多数情况下,所有其他表都有一个自动递增的整数或唯一标识符主键。

问题:-)

我最近开始使用一些数据库,这些数据库没有一致的行标识符,而且主键目前聚集在各个列之间。一些例子:

datetime /字符 datetime /整数 datetime / varchar 字符/ nvarchar / nvarchar

这有有效的理由吗?我总是为这些情况定义一个标识符或唯一标识符列。

此外,还有许多根本没有主键的表。如果有的话,合理的理由是什么?

我试图理解为什么桌子被设计成这样,对我来说,它似乎是一个很大的混乱,但也许有很好的理由。

第三个问题在某种程度上帮助我解析答案:在使用多个列组成复合主键的情况下,与代理/人工键相比,这种方法是否有特定的优势?我主要考虑的是性能、维护、管理等方面。


当前回答

我将坦率地说明我对自然键的偏好——在可能的情况下使用它们,因为它们将使您的数据库管理工作更加容易。我在公司建立了一个标准,所有的表格都有以下列:

行ID (GUID) 创造者(字符串;有一个默认的当前用户名(SUSER_SNAME()在T-SQL)) 创建(DateTime) 时间戳

行ID在每个表上都有一个唯一的键,并且在任何情况下都是每行自动生成的(并且权限阻止任何人编辑它),并且合理地保证在所有表和数据库中是唯一的。如果任何ORM系统都需要一个ID密钥,那么可以使用这个密钥。

同时,如果可能的话,实际的PK是一个自然的关键。我的内部规则是这样的:

人-使用代理键,例如INT。如果它是内部的,那么Active Directory用户GUID是一个可以接受的选择 查找表(例如StatusCodes) -使用短的CHAR代码;它比int更容易记住,在许多情况下,纸张表格和用户也会使用它来简洁(例如,Status = "E"表示"过期","A"表示"已批准","NADIS"表示"样品中未检测到石棉")。 链接表- fk的组合(例如EventId, AttendeeId)

因此,理想情况下,您最终会得到一个自然的、人类可读的和难忘的PK,以及一个orm友好的每个表一个id的GUID。

警告:我维护的数据库倾向于100,000条记录,而不是数百万或数十亿条记录,所以如果您有使用大型系统的经验,这不利于我的建议,请随意忽略我!

其他回答

如果有天然钥匙,通常是最好的。因此,如果datetime/char唯一地标识了行,并且这两部分对行都有意义,那就太好了。

如果只有datetime是有意义的,并且只是附加了char以使其唯一,那么您不妨使用一个identify字段。

我也总是使用数字ID列。在oracle中,我使用数字(18,0)没有真正的原因高于数字(12,0)(或任何int而不是long),也许我只是不想担心在db中获得数十亿行!

我还包括了一个用于基本跟踪的已创建和修改的列(类型时间戳),在这里它似乎很有用。

我不介意在其他列的组合上设置唯一的约束,但我非常喜欢我的id、创建和修改的基线需求。

我们做了很多连接,复合主键已经成为性能的累赘。简单的int或long即使引入第二个候选键也可以解决许多问题,但是在一个字段上连接比在三个字段上连接要容易得多,也更容易理解。

我遵循一些规则:

Primary keys should be as small as necessary. Prefer a numeric type because numeric types are stored in a much more compact format than character formats. This is because most primary keys will be foreign keys in another table as well as used in multiple indexes. The smaller your key, the smaller the index, the less pages in the cache you will use. Primary keys should never change. Updating a primary key should always be out of the question. This is because it is most likely to be used in multiple indexes and used as a foreign key. Updating a single primary key could cause of ripple effect of changes. Do NOT use "your problem primary key" as your logic model primary key. For example passport number, social security number, or employee contract number as these "natural keys" can change in real world situations. Make sure to add UNIQUE constraints for these where necessary to enforce consistency.

关于代理键和自然键,我参考了上面的规则。如果自然键很小并且永远不会改变,则可以将其用作主键。如果自然键很大或可能改变,我使用代理键。如果没有主键,我仍然会创建一个代理键,因为经验表明,您总是会向模式添加表,并希望在适当的位置放置一个主键。

表应该一直有一个主键。如果没有,它应该是一个自动递增字段。

有时人们会省略主键,因为他们要传输大量数据,这可能会减慢(取决于数据库)进程。但是,它应该加在它之后。

一些关于链接表的评论,这是正确的,这是一个例外,但是字段应该是FK以保持完整性,并且在某些情况下,如果链接中的重复没有被授权,这些字段也可以是主键…但是要保持简单的形式,因为异常在编程中经常出现,所以应该提供主键来保持数据的完整性。