SQL Server - Hub/Spoke disconnect model

Question

Вот моя ситуация. Я знаю, что это не первый раз, когда он появился, но я не могу найти нужную документацию для решения всех моих проблем ... у нас есть среда, где необходимо создать централизованный/свернутый веб-сервис и хранилище данных для кучи магазинов, и каждый магазин также будет иметь локальные ресурсы (тот же БД, локальный веб-сервис).

Идея состоит в том, что все работает как централизованное решение - все проходит через хранилище данных до тех пор, пока сеть не работает, но когда сетевая ссылка идет вниз, мы хотим, чтобы магазины не спаслись, полагаясь на свою локальную веб-службу/DB. Конечно, когда связь возвращается, спицы каждый из них вынуждают свои оффлайновые x-действия обратно в хранилище данных.

В нормальных условиях вновь добавленные строки должны также существовать в локальной БД магазина, как только они будут записаны в хранилище данных, поэтому, если ссылка сломана, у магазина есть свои данные вплоть до последней секунды (это было бы иронично, если бы у вас не было собственных данных о хранилищах, когда связь была отключена, но все же - она ​​должна пройти через DW для целостности).

Я не хочу, чтобы реплики всех важных таблиц в спицах (хотя я предполагаю, что это решило бы проблему), например «Offline_Transactions», «Offline_Orders» и т. Д., Потому что #/таблицы для управления будет огромным.

Это обратная запись (нормальные действия x, нажимая строки DW на спицы, чтобы они всегда были текущими), что создает проблему, я думаю. Поскольку это может привести к тому, что БД не синхронизируется (если запись записывается в DW, но ссылка опускается или служба не работает, когда пытается копировать строку на спицу), даже составной ключ с StoreId + RowId может потенциально содержат дубликаты.

Так что я думал, что сделаю это с нулевым столбцом GUID, который используется только в режиме «офлайн» на спицах. При нормальных операциях этот столбец был бы нулевым (когда DW сначала создает строку и копируется обратно в базу данных DB). Когда ссылка отключена, а БД для хранения в хранилище создает «отдельные» записи, они будут содержать GUID для гарантированной уникальности, а затем, когда ссылка будет восстановлена, будет запущен процесс, который вызывает веб-службу центрального DW, чтобы объединить эти строки в DW.

Проблема, с которой я сталкиваюсь с любым решением, которое я придумал, - это кластеризованный индекс. Там должен быть один для производительности, но если данные с обеих сторон потенциально могут иметь нули в важных столбцах (в записях будут указаны идентификаторы GUID, но нет последовательных значений столбцов идентификатора, а записи DW будут иметь идентификационные значения, но не GUID), то либо схемы должны быть разными (чего я хочу избежать), или это решение выходит из строя.

То, что я планирую делать, это сложный кластерный индекс, использующий оба col: GUID и истинный инкрементирующий ID. Мое мышление заключается в том, что на стороне DW это не должно иметь никакого влияния, потому что не будет никаких GUID для решения, они будут удалены, поскольку данные будут перенесены в центральный репозиторий со спиц. Он должен действовать/выполнять так же, как стандартный кластерный индекс в столбце идентификатора, правильно?

Выгода - я надеюсь - это то, что я могу использовать ту же схему на спицах, и когда будут добавлены строки «отсоединенные», они сохранят свою уникальность на всем протяжении, и хотя индексирование может быть изворотливым, пока ссылка не работает, мы не будет иметь дело с миллионами или даже тысячами строк, используя GUIds, всего лишь несколько, пока связь не будет восстановлена, а затем, когда две среды будут синхронизироваться, все будет хорошо снова.

Итак, пожалуйста, скажите мне, почему это худшая идея когда-либо, и/или указывать на более простые/лучшие способы управления этим или вообще помочь мне.

TIA.

Answer 1

У вас будут сумасшедшие прецеденты, если у вас нет полномочий для данных.

Вот что я имею в виду. Если данные, управляемые хранилищем (то есть данные, которые он изменит при отключении), могут быть изменены другими сторонами (скажем, другим складом), тогда, когда он поступит в Интернет, это будет очень трудное решение (без того, чтобы кто-то это делал вручную).) Я говорю, что у меня было 10 случаев, и теперь у меня 20 случаев, но кто-то другой изменил его с 10 случаев до 5 случаев (возможно, они хотели их заказать). Как вы разрешите это ... если значение будет 5 10, 20, 15?

Это очень быстро.

Если вы не разрешаете это, тогда вы в безопасности, если у вас есть данные, принадлежащие сторонам, которые могут изменить его в автономном режиме, тогда у вас есть гораздо более простой процесс - верните отправку обновлений, это официальные правильные значения. Возможно, другой склад может сделать запрос, но не изменить эти значения.

Я думаю, вам нужно разработать эти многопользовательские правила, прежде чем вы начнете думать о своей модели данных, потому что это будет иметь эффект.