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

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

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

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

问题:-)

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

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

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

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

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

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


当前回答

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

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

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

其他回答

您应该使用由多个字段组成的“复合”或“复合”主键。

这是一个完全可以接受的解决方案,点击这里了解更多信息:)

我总是使用自动编号或标识字段。

我曾经为一个客户工作,他使用SSN作为主键,然后由于HIPAA法规被迫更改为“MemberID”,这在更新相关表中的外键时引起了大量问题。坚持一致的标识列标准帮助我在所有项目中避免了类似的问题。

我遵循一些规则:

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.

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

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

行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字段。