这是对复杂系统的非常简单的描述。以下商店和服务有大量的关系和数百万条各种类型的记录。此外，它还被多个应用程序使用。
我有一个项目，由一堆包含大量服务的商店组成。这是简单的关系。这些服务中的大多数变化不大。但很多时候，新商店是通过复制现有商店来创建的，这需要复制所有服务。
一位客户希望商店支持母公司。因此，母公司可以拥有一个或多个商店。这主要用于报告目的，不影响与商店和服务的关系。这已经完成了，没什么大不了的。
现在我们有一个客户说，他们希望母公司能够创建服务并将它们推送到特定的商店。但由于商店遍布全球，每项服务都需要有自己的定价（还有库存考虑）。从表面上看，有两种基本方法。首先，我们可以有一个在商店之间共享的母公司服务记录，并提供不同的数据库结构来保存每个商店的定价。这样做的主要问题是每个应用程序现在都需要提供服务的 ID 和商店 ID，以确保它正在读取正确的服务数据。对于常规加载和搜索，需要额外的表连接，这会增加更多的数据库开销。
第二种解决方案我们可以为每个商店创建一个母公司服务记录的副本。所以不需要创建新的数据库实体（除了一些对母公司的引用）。所有代码都可以在不知道更改的情况下正常运行。这将需要同步服务，以确保每当母公司级别的服务发生变化时，所有商店都会更新。此外，添加到母公司的任何新商店都需要添加共享服务。
从标准化的角度来看，第一个解决方案似乎是最好的。但是从维护来看，第二个更容易实现，并且需要对服务处理方式进行较少的更改。然而同步过程是一个潜在的失败点，但它不应该经常使用。
那么这两种方法的共识是什么？