使用中央 ID 存储或根据表分配 ID 哪个更好
Which is better, using a central ID store or assigning IDs based on tables
在许多 ERP 系统（本地）中，我看到数据库（通常 MYSQL）使用中央密钥存储（资源标识）。这是为什么？
即在数据库中，维护一个特殊的 table 用于生成 ID，该 ID 将具有一个单元格（第一个单元格），该单元格将具有分配给后续元组的数字（ID）（即所有 [= 的通用 ID 生成） 22=]s 在同一数据库中）。
同样在此 table 中插入了最后插入的批次详细信息的条目。即，当插入 table ABC 中的 5 个元组时，假设批次中项目的最后一个 ID 是 X，则 table（中央密钥库）中的条目也被插入，如 ('ABC', X).
这个架构有什么意义吗？
以及在哪里可以找到常见的大型定制 ERP 系统的案例研究？
这是数据仓库中常用的策略，用于在数据加载成功或失败后跟踪批号，以防数据加载失败你会说 'ABC' , 'Batch_num' 和批处理控制 table 中的 'Error_Code'，因此您的进一步加载逻辑可以决定如何处理失败并且可以轻松跟踪加载，以防万一您想要重新检查我们可以存档数据。此 ID 通常由数据库中的序列生成，总之主要用于 监控 目的。
您可以参考此link了解更多详情
这种设计的缺点是在插入新数据时会给中央 table 带来巨大的负载。这是一个内置的瓶颈。
一些“优势”是：
- 无论类型如何，都可以轻松识别在系统中任何位置找到的任何资源 ID。
- 如果 table 中有任何文本（例如名称或描述），那么它们都是集中的，便于多语言支持。
- 外键引用可以跨多种类型工作。
第三个并不是真正的优势，因为它有一个缺点：无法为外键引用指定特定类型。
如果我理解正确的话，你是在问为什么有人会替换仅对 table
唯一的 ID
- TABLE 客户（id_client AUTO_INCREMENT，姓名，地址）
- TABLE 产品（id_product AUTO_INCREMENT，名称，价格）
- TABLE 订单（id_order AUTO_INCREMENT, id_client, 日期）
- TABLE order_details (id_order_detail AUTO_INCREMENT, id_order, id_product, 金额)
具有在整个数据库中唯一的全局 ID
- TABLE 个对象（id AUTO_INCREMENT）
- TABLE 客户（id_object、姓名、地址）
- TABLE 产品（id_object、名称、价格）
- TABLE 订单（id_object，id_object_客户，日期）
- TABLE order_details (id_object, id_object_order, id_object_product, amount)
（当然，您仍然可以将这些 ID 称为 id_product 等，而不是 id_object。我使用名称 id_object 只是为了说明。）
第一种方法是常见的方法。在 table 中插入新行时，您会获得 table 的下一个可用 ID。如果两个session要同时插入，一个session需要稍等一下。
因此，第二种方法会导致会话在每次想要插入数据时都等待轮到他们，而不管 table 是什么，因为它们都从对象 table 中获取 ID。最大的优势是在导出数据时，您拥有全局引用。假设您出口订单，收件人告诉您：“我们对您的订单详细信息 12345 有疑问。您的数据一定有问题”。如果您可以告诉他们“12345 不是订单详细信息 ID，而是产品 ID。您在导入产品时遇到问题还是可以告诉我这是关于什么的订单详细信息 ID，那不是很好吗？”而不是查看恰好有数字 12345 的小时订单详细记录，虽然它与问题无关，真的吗？
也就是说，使用第一种方法并将 UUID 添加到您用于外部通信的所有 table 可能是更好的选择。没有为下一个 ID 而战，并且仍然没有在通信中弄错 ID :-)
还有其他几种技术，每种技术各有利弊。但是，让我首先指出在扩大规模的某个时刻遇到障碍的两种技术。假设您有数十亿个项目，可能通过分片或其他技术分散在多个服务器上。
砖墙 #1：UUID 很方便，因为客户端可以创建它们而无需向某些中央服务器询问值。但是 UUID 是非常随机的。这意味着，在大多数情况下，每个引用都会导致磁盘命中，因为 id 不太可能被缓存。
砖墙 #2：询问中央服务器，它有一个 AUTO_INCREMENT 在幕后分发 ID。我看到一个社交媒体网站除了收集用于分享的图片外什么都不做，因此导致崩溃。尽管有一个服务器的唯一目的是分发数字。
解决方案 #1：
这里有一个（几个）解决方案可以避免大多数问题：有一个中央服务器一次分发 100 个 ID。在客户端用完给定的 100 之后，它会请求新的一批。如果客户端崩溃，最后 100 个中的一些将“丢失”。那好吧;没什么大不了的。
该解决方案是砖墙 #2 的 100 倍以上。而且这些 ID 的随机性远低于砖墙 #1。
解决方案 #2：每个客户端都可以生成自己的 64 位半顺序 ID。该数字包括版本号、一些时钟、dedup-part 和 client-id。所以它大致是按时间顺序排列的（全世界），并且保证是独一无二的。但对于大约同时创建的项目，仍然具有良好的参考位置。
注意：我的技术可以适用于单个表格或作为所有表格的超级号码。这种区别可能是您 'real' 的问题。 （其他答案解决了这个问题。）
在许多 ERP 系统（本地）中，我看到数据库（通常 MYSQL）使用中央密钥存储（资源标识）。这是为什么？
即在数据库中，维护一个特殊的 table 用于生成 ID，该 ID 将具有一个单元格（第一个单元格），该单元格将具有分配给后续元组的数字（ID）（即所有 [= 的通用 ID 生成） 22=]s 在同一数据库中）。
同样在此 table 中插入了最后插入的批次详细信息的条目。即，当插入 table ABC 中的 5 个元组时，假设批次中项目的最后一个 ID 是 X，则 table（中央密钥库）中的条目也被插入，如 ('ABC', X).
这个架构有什么意义吗？
以及在哪里可以找到常见的大型定制 ERP 系统的案例研究？
这是数据仓库中常用的策略，用于在数据加载成功或失败后跟踪批号，以防数据加载失败你会说 'ABC' , 'Batch_num' 和批处理控制 table 中的 'Error_Code'，因此您的进一步加载逻辑可以决定如何处理失败并且可以轻松跟踪加载，以防万一您想要重新检查我们可以存档数据。此 ID 通常由数据库中的序列生成，总之主要用于 监控 目的。
您可以参考此link了解更多详情
这种设计的缺点是在插入新数据时会给中央 table 带来巨大的负载。这是一个内置的瓶颈。
一些“优势”是：
- 无论类型如何，都可以轻松识别在系统中任何位置找到的任何资源 ID。
- 如果 table 中有任何文本（例如名称或描述），那么它们都是集中的，便于多语言支持。
- 外键引用可以跨多种类型工作。
第三个并不是真正的优势，因为它有一个缺点：无法为外键引用指定特定类型。
如果我理解正确的话，你是在问为什么有人会替换仅对 table
唯一的 ID- TABLE 客户（id_client AUTO_INCREMENT，姓名，地址）
- TABLE 产品（id_product AUTO_INCREMENT，名称，价格）
- TABLE 订单（id_order AUTO_INCREMENT, id_client, 日期）
- TABLE order_details (id_order_detail AUTO_INCREMENT, id_order, id_product, 金额)
具有在整个数据库中唯一的全局 ID
- TABLE 个对象（id AUTO_INCREMENT）
- TABLE 客户（id_object、姓名、地址）
- TABLE 产品（id_object、名称、价格）
- TABLE 订单（id_object，id_object_客户，日期）
- TABLE order_details (id_object, id_object_order, id_object_product, amount)
（当然，您仍然可以将这些 ID 称为 id_product 等，而不是 id_object。我使用名称 id_object 只是为了说明。）
第一种方法是常见的方法。在 table 中插入新行时，您会获得 table 的下一个可用 ID。如果两个session要同时插入，一个session需要稍等一下。
因此，第二种方法会导致会话在每次想要插入数据时都等待轮到他们，而不管 table 是什么，因为它们都从对象 table 中获取 ID。最大的优势是在导出数据时，您拥有全局引用。假设您出口订单，收件人告诉您：“我们对您的订单详细信息 12345 有疑问。您的数据一定有问题”。如果您可以告诉他们“12345 不是订单详细信息 ID，而是产品 ID。您在导入产品时遇到问题还是可以告诉我这是关于什么的订单详细信息 ID，那不是很好吗？”而不是查看恰好有数字 12345 的小时订单详细记录，虽然它与问题无关，真的吗？
也就是说，使用第一种方法并将 UUID 添加到您用于外部通信的所有 table 可能是更好的选择。没有为下一个 ID 而战，并且仍然没有在通信中弄错 ID :-)
还有其他几种技术，每种技术各有利弊。但是，让我首先指出在扩大规模的某个时刻遇到障碍的两种技术。假设您有数十亿个项目，可能通过分片或其他技术分散在多个服务器上。
砖墙 #1：UUID 很方便，因为客户端可以创建它们而无需向某些中央服务器询问值。但是 UUID 是非常随机的。这意味着，在大多数情况下，每个引用都会导致磁盘命中，因为 id 不太可能被缓存。
砖墙 #2：询问中央服务器，它有一个 AUTO_INCREMENT 在幕后分发 ID。我看到一个社交媒体网站除了收集用于分享的图片外什么都不做，因此导致崩溃。尽管有一个服务器的唯一目的是分发数字。
解决方案 #1：
这里有一个（几个）解决方案可以避免大多数问题：有一个中央服务器一次分发 100 个 ID。在客户端用完给定的 100 之后，它会请求新的一批。如果客户端崩溃，最后 100 个中的一些将“丢失”。那好吧;没什么大不了的。
该解决方案是砖墙 #2 的 100 倍以上。而且这些 ID 的随机性远低于砖墙 #1。
解决方案 #2：每个客户端都可以生成自己的 64 位半顺序 ID。该数字包括版本号、一些时钟、dedup-part 和 client-id。所以它大致是按时间顺序排列的（全世界），并且保证是独一无二的。但对于大约同时创建的项目，仍然具有良好的参考位置。
注意：我的技术可以适用于单个表格或作为所有表格的超级号码。这种区别可能是您 'real' 的问题。 （其他答案解决了这个问题。）