在数据库中使用ID

Question

在数据库中创建新表时,使用id的重要性是什么.出于我们的目的,我们在每个字段中使用唯一的用户名和电子邮件,以将信息与唯一的用户名或电子邮件相匹配.那么id的用途是什么？

另外,长度/值字段是什么？新的.

谢谢一堆!

Answer 1

该id字段是代理键的示例.使用代理键作为数据库中的主键是一个好主意,因为它与现实世界中的外部事件完全无关,因此不受其影响.

使用诸如电子邮件地址之类的自然键可能会导致问题,因为如果用户更改其电子邮件地址,您的密钥将不得不更改.这会造成困难,因为它会打破外键的限制.它还将使查询与特定用户相关的事件随着时间的推移变得更加困难,因为您没有保证与该用户的整个历史记录一致的单个密钥.

如果公司中有多个需要密钥的数据库,或者将数据从数据库导出到其他应用程序或系统,那么当您更改数据库中的密钥时,您可能还需要更改这些系统中的密钥,使用ON CASCADE UPDATE无法自动完成.

Answer 2

正如其他人指出的那样，记录有两种类型的密钥：自然密钥和代理（人工）密钥。那么，两个主要问题是：您是否需要使用代理键，如果需要，代理键应该是什么？

关于第一个问题：如果没有有效的自然键用作表上的主键，则只需使用代理键。所有健全的数据库系统都支持“ON UPDATE CASCADE ”子句，这意味着如果您使用的自然键发生更改，则更改将传播到声明引用它的所有内容。当然，如果您的数据库系统不支持外键，那么您最好的选择是使用代理键，即使只是为了解决数据库系统中功能的缺乏（并且代理键将使您的数据库更容易进行一致性检查）鉴于这一事实）。也就是说，如果您正在设计一个需要高正常运行时间和高稳健性的应用程序，请选择一个能够正确获取外键的数据库实现，否则您很可能会发现在开发后期（甚至在维护过程中）会发现数据完整性错误）并且您将必须编写实用程序来检查数据在各种故障模式下的一致性。

对于第二个问题：如果您使用代理键，特别是当您正在解决数据库系统的缺陷时，您应该始终将其视为不可变且全局唯一的。 总是。 这将在以后的许多情况下有所帮助：公司可以合并（和拆分），数据库可以合并（和拆分），并且可能会发生大约一百万种其他情况，这些情况在数据库设计时没有预料到，这些情况可能会导致问题如果代理键不是全局唯一的。由于代理键与它们所保存的数据完全无关（除了您赋予它的人工字段之外，它们与表中的其他字段没有关系），因此最好是这种方式。由于这些原因，当我必须使用代理键时，我会使用 UUID（本质上是一个 128 位整数，但不是增量整数）。现在，当发生意外事件时，您不必担心对记录编号和引用进行重新编号。（是的，它确实会减慢速度，特别是如果您的服务器运行在 32 位平台上。但是，如果您需要处理更多负载，请更好地分配负载——永远不要为了速度而牺牲完整性，当您正在处理重要数据！）