这是我的情况 - 我知道这不是第一次出现但是我找不到合适的文件来解决我的所有问题....我们有一个需要集中/滚动的环境一堆商店和每个商店的特定网络服务和数据仓库也将拥有本地资源（相同的数据库，本地网络服务）。
这个想法是一切都可以作为一个集中的解决方案 - 只要网络运行，一切都在数据仓库中运行，但是当网络链接出现故障时，我们希望商店依靠他们的本地Web服务来保持高效/数据库实例。当然，当链接返回时，每个辐条都需要将其脱机x动作推回到数据仓库。
在正常情况下，一旦将新添加的行写入数据仓库，它们也应存在于商店的本地数据库中，因此如果链接被破坏，则商店会有自己的数据直到最后一秒（它会具有讽刺意味的是，当链接出来时没有自己的商店数据，但仍然 - 它必须通过DW才能保持完整性。）
我不想要辐条中所有重要表的副本（虽然我猜这会解决问题），例如“Offline_Transactions”，“Offline_Orders”等，因为要管理的＃/表正在进行中变得巨大。
这是回写（正常的x动作，将DW行推回到辐条，所以它们总是当前的），这会产生问题，我想。因为这可能会导致数据库不同步（如果记录在DW中写入但链接断开或服务在尝试将行复制到辐条时关闭），即使具有StoreId + RowId的复合键也可能包含重复项。
所以我认为我会做的是一个可以为空的GUID列，它仅用于辐条的“离线”模式。在正常操作下，此列将为null（当DW首先创建行并将其复制回商店的辐条数据库时）。当链接断开且商店的辐条DB正在创建“分离”记录时，它们将包含GUID以保证唯一性，然后当链接恢复时，将运行一个进程，调用中央DW的Web服务将这些行合并到DW中。
我遇到的任何解决方案都遇到的问题是聚簇索引。必须有一个性能，但如果任何一方的数据可能在重要列中具有空值（辐条记录将具有GUID但没有顺序，标识列值和DW记录将具有ID值但没有GUID）则模式必须不同（我想避免）或者此解决方案失败。
我正在考虑的是使用两个col的复合聚簇索引：GUID和真正的递增ID。我的想法是，在DW方面，它不会产生任何影响，因为没有任何GUID可以处理，当数据从辐条推送到中央存储库时，它们将被剥离。它应该像ID列上的标准聚簇索引一样执行/执行，对吗？
好处 - 我希望 - 是我可以在辐条上使用相同的模式，并且当添加“分离”行时，它们将始终保持其唯一性，而当链接断开时索引可能是狡猾的，我们赢了使用GUId处理数百万甚至1,000行，只需要几次直到链接恢复，然后一旦两个环境同步备份，一切都很好。
所以 - 请告诉我为什么这是最糟糕的想法，并且/或者指出更容易/更好的方法来管理这个，或者通常帮助我。
TIA。
答案 0 :(得分：0)
如果您没有数据权限，您将会遇到疯狂的用例。
这就是我的意思。如果仓库控制的数据（即离线时它将改变的数据）可由其他方（例如另一个仓库）更改，那么当它上线时，将很难解决混乱（没有人手动完成）。 ）我说我有10个病例，现在我有20个病例，但有人将其从10个病例改为5个病例（也许他们想要订购）。你如何解决这个问题......如果价值是5 10,20,15？
这快速变得非常复杂。
如果您不允许这样，那么您是安全的，如果您拥有可以离线修改它的各方拥有的数据，那么您有一个更简单的过程 - 回来发送更新，这些是正式的正确值。也许另一个仓库可以提出请求，但不能更改这些值。
我认为您需要在开始考虑数据模型之前设计这些多用户规则，因为它会产生影响。