我有一个由GUID标识的对象。我将它存储在SQL DB中并设计表。我应该使用guid作为PK还是应该创建一个aditional ID字段?我永远不会使用我知道的ID字段。这种情况有什么好处?我看到它的创造可能是他们的动机?
答案 0 :(得分:2)
您是否还需要代理键取决于您的特定需求。 GUID加入速度可能较慢,但只有您可以知道它们是否会影响系统性能,足以保证添加一个int键。 GUID还存在问题以及数据如何物理存储在磁盘上以及导致的性能问题。另外,由于PK存在于所有其他索引中,因此使用PK的GUID可以大大增加索引的大小。在承诺使用GUID之前,您需要对性能影响(可能与数据库到数据库不同)进行一些阅读。
GUIDS不是用户友好的。如果你在表中没有一个好的自然键(例如人名表,其中名称不是唯一的,因此不能成为自然键),那么用户可能需要有一些其他值来查询(例如person_id) )。普通员工比客户'6214304C-2C56-E011-BACB-00265582C0F2更快乐地研究客户1234'我也不认为客户想要打电话给客户服务寻求订单号码'6E14304C-2C56-E011-的帮助BACB-00265582C0F2' 。这不是一个不重要的考虑因素。
我并不是说你不能使用GUID(你当然可以),但是在你提交路径之前你需要知道使用GUID可能会遇到什么样的问题。在有数百万条记录之后,数据库不容易改变,特别是对于像PK这样的设计至关重要的东西。在您拥有大量记录之前,GUID的许多问题并不是特别明显。如果数据库是永远不会具有该级别记录的数据库,则可能永远不会遇到问题,但您需要在决定之前考虑自己预期的数据库使用方面的影响。
答案 1 :(得分:1)
一张桌子应该至少有一把钥匙,但是如果你不需要它,就没有理由再制作另一把钥匙。
答案 2 :(得分:0)
一种可能的情况是,您有来自另一个拥有自己GUID的数据库/系统的记录。
答案 3 :(得分:0)
了解我们理解应用程序所需的动力。
没有理由的原因: Guid就是你需要访问,搜索,检索,记录的所有内容
有一个理由: 信息在数据中虚拟化。这意味着guid虽然足以满足数据库的观点,但可能不适合用户的观点。当根据业务流程考虑时,附加ID字段可以是主要字段,并且在其他系统中使用该字段的内容
答案 4 :(得分:0)
如果不了解更多有关您的业务需求的话,很难权威地回答。使用自然主键肯定是合法的。在此扩展您的要求,或在natural and synthetic primary keys上阅读。