Дизайн SQL с учетом отсутствия ссылок на внешние ключи между базами данных

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

Предполагая, что каждый модуль настроен так, что он связан с административной базой данных, вы можете упростить задачу, настроив представления для административных таблиц в каждой модульной базе данных.

В зависимости от реализации вашей базы данных вы часто сможете связать таблицы из другой базы данных (AdminDB), и они появятся в ваших различных базах данных модулей.

В Microsoft Access вы можете связать таблицы, щелкнув правой кнопкой мыши и выбрав источник данных ODBC. В Oracle они называют это ссылкой на базу данных. Я готов поспорить, что SQLServer имеет некоторую форму этой реализации не реализует настраиваемую репликацию для одной таблицы.

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

Второй вариант может быть еще проще. Что, если бы вы использовали одну и ту же схему для всех модулей и базы данных администратора? Вы знаете, что база данных администратора присутствует, поэтому просто запустите сценарий создания таблицы для этой схемы. Пока нет конфликтов именования таблиц / представлений / хранимых процедур, тогда все должно работать, просто изменив dblogin во всех модулях на соответствие.

У нас такая модульность в наших продуктах, но наши требования к базе данных объединяются во время установки. Например, наш административный пакет и продукт A могут быть первоначальной покупкой клиентом, при котором они устанавливают два модуля в базу данных X. Если они позже купят продукт B, компонент базы данных размещается прямо поверх базы данных X, добавляя в DRI, где это необходимо.

Единственный случай, когда я увидел необходимость в отдельных базах данных с точки зрения дизайна, - это когда вы проводите жесткую границу между бизнес-единицами (например, корпорацией), и в этот момент проблема действительно связана с типом разделения. Great Plains Dynamics делает это там, где у них есть одна административная база данных и несколько корпоративных баз данных. Однако каждый модуль в GP для данной корпорации находится в этой единой базе данных.

Конечно, если вы застряли с отдельными базами данных, я соглашусь, что D - лучший вариант.

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

Если вы скажете: «Ну и дела, есть еще много работы, которую можно было бы сделать без admin db». тогда я бы спросил, почему вы считаете, что однонаправленная репликация настолько экзотична, что это явный рецепт катастрофы?

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

Я не говорю, что это ИДЕАЛЬНЫЙ способ, вы должны сначала ответить на мой первоначальный вопрос. После этого, если вы действительно хотите продолжить работу ... не сбрасывайте со счетов жизнеспособность репликации.

Интересно, есть ли у SQL Server такая функция, как материализованные представления Oracle? Это объект, который вы определяете с помощью запроса, такого как представление, но результаты запроса сохраняются в виде таблицы. Затем существуют различные механизмы для автоматического обновления.

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

Вам следует реализовать сервис-ориентированную архитектуру. Где разные службы в системе работают со своей схемой базы данных. Тогда позвольте вашим приложениям работать независимо от любых баз данных, но позволить им работать против сервисов.

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

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

В этих случаях я обычно полагаюсь на отчеты об исключениях, генерируемые ежечасно, которые проверяют состояние вещей и сообщают только в случае возникновения проблемы. Задания агента SQL Server обладают мощными возможностями планирования. Я всегда использовал таблицы журналов и SQLAnswersMail для создания красивых небольших электронных писем в формате HTML (где URL-ссылки в электронных письмах могут даже привести вас на страницы администрирования для устранения проблем) различным системным администраторам, но есть множество способов избавиться от этой кошки.

Я думаю, что самое забавное ... вы можете сделать небольшую копию базы данных MS Access, применить RI в Access ... и затем увеличить размер, и Microsoft Access дает вам возможность выбирать между использованием триггеров или DRI ... и я Я почти уверен, что Microsoft Access напишет за вас основные части триггеров.

Пока мы обсуждаем эту тему, я ненавижу MS Access ... но одна вещь, которая превосходит Access, это то, что вы можете принудительно использовать RI против QUERY (sql select, aka view). Я действительно хочу, чтобы у MS SQL Server был та же функциональность.