我需要ID字段吗？

Question

我有一个由GUID标识的对象。我将把它存储在SQL DB中并设计表格。我应该使用guid作为PK还是应该创建一个aditional ID字段？我永远不会使用我知道的ID字段。这种情况有什么好处？我看到它创造了什么可能是他们的动机？

Answer 1

无论您还需要一个代理键取决于您的特定需求。加入GUIDS可能会比较慢，但是只有您可以知道它们是否会影响系统的性能才能保证添加int键。 GUIDS也存在问题，以及数据如何物理存储在磁盘上以及导致的性能问题。此外，由于PK在所有其他索引中，对PK使用GUID可以大大增加索引的大小。在提交使用GUID之前，您需要阅读性能影响（这可能会因数据库不同而不同）。

GUIDS不方便用户使用。如果你在表中没有一个好的自然键（例如人名表不是唯一的，因此不能成为一个自然键），那么用户可能需要有其他值来查询（比如person_id ）。与客户的6214304C-2C56-E011-BACB-00265582C0F2相比，普通员工对研究客户1234的兴趣会更高。'我也不认为客户想要致电客户服务部门以寻求订单号'6E14304C-2C56-E011- BACB-00265582C0F2' 。这不是一个不重要的考虑。

我不是说你不能使用GUID（你当然可以），但你需要知道你承诺什么类型的问题，你可能有使用GUID的路径之前。 Databasesa在有数百万条记录之后不容易改变，特别是对于设计来说至关重要的是PK。许多有关GUID的问题在你有很多记录之前并不特别明显。如果数据库是永远不会有这种级别的记录的数据库，那么您可能永远不会遇到这个问题，但是您需要在决定之前根据自己的预期数据库使用情况考虑这些影响。

Answer 2

一种可能的情况是，当你从另一个数据库/系统，它有它自己的GUID来的记录。

Answer 3

了解我们需要了解应用程序的动机。

理由不有一个： GUID是所有你需要的访问，检索算法，检索，胡说记录

原因有一个： 信息数据中虚拟化。对于DB角度来说足够的指导意义，可能不适合用户的观点。在其它附加ID字段可能是当在业务流程中考虑的主要领域，该领域的其他系统中使用的内容

Answer 4

这是很难回答权威性不知道更多关于您的业务需求。使用自然主键当然可能是合法的。在此扩展您的要求，或者在natural and synthetic primary keys上阅读。

Answer 5

一个表至少应该有一个关键，但没有理由创造一个又一个，如果你不会需要它。