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

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

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

Мои варианты, которые я вижу, следующие:

a) Наложить псевдо-внешний ключ с помощью триггеров (нормально, но немного работы)

b) Используйте триггеры для репликации из admin в другие базы данных (ясный рецепт для бедствия)

c) Настроить внешний ключ puedo в коде /DAL (плохо работает с ORM)

d) Не беспокойтесь об этом на уровне БД, используйте хороший дизайн пользовательского интерфейса, чтобы убедиться, что никто не делает что-то глупое и не ограничивает доступ/удержание дыхания при прямом доступе SQL.

Честно говоря, я склонен пойти с "D", но решил, что я выйду за мнения умнее меня...

Ответ 1

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

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

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