Обмениваться данными напрямую или делать копии
Это очень простое описание сложной системы. У нижеуказанных магазинов и услуг есть тонны отношений и миллионы записей различных типов. Плюс он используется несколькими приложениями.
У меня есть проект, который состоит из множества магазинов, которые содержат множество услуг. Это простое отношение. Большинство этих услуг не сильно меняются. Но много раз новые магазины создаются путем копирования существующего магазина, который требует копирования всех сервисов.
Клиент хотел, чтобы магазины поддерживали материнские компании. Таким образом, материнская компания может иметь один или несколько магазинов. Это в основном для целей отчетности и не влияет на отношения с магазинами и услугами. Это сделано и не имеет большого значения.
Теперь у нас есть клиент, который говорит, что хочет, чтобы материнская компания могла создавать сервисы и отправлять их в определенные магазины. Но поскольку магазины расположены по всему миру, каждая услуга должна иметь свою собственную цену (есть также соображения относительно запасов). На поверхности есть два основных подхода. Во-первых, у нас может быть одна служебная запись родительской компании, которая распределяется между магазинами и предоставляется другая структура БД для хранения цен для каждого магазина. Основная проблема заключается в том, что теперь каждому приложению необходимо предоставить идентификатор службы и идентификатор хранилища, чтобы обеспечить правильное считывание данных службы. Для регулярных загрузок и поисков требуется дополнительное объединение таблиц, которое увеличивает накладные расходы.
Вторым решением мы можем создать копию сервисной записи материнской компании для каждого магазина. Таким образом, не нужно создавать новую сущность БД (за исключением нескольких ссылок на материнскую компанию). Весь код может работать как обычно без знания изменений. Это потребует службы синхронизации, чтобы при каждом изменении службы уровня родительской компании все магазины обновлялись. Кроме того, для всех новых магазинов, добавленных в материнскую компанию, необходимо добавить общие службы.
С точки зрения нормализации первое решение кажется наилучшим. Но от обслуживания второе легче реализовать и требует меньше изменений в том, как обрабатываются сервисы. Однако процесс синхронизации является потенциальной точкой отказа, но его не следует использовать очень часто.
Так каков консенсус с двумя подходами?