База данных на приложение VS Одна большая база данных для всех [закрытых] приложений

Ни тот, ни другой путь не выглядит идеальным

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

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

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

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

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

Мои 2 цента.

Это вообще не звучит как «много приложений», а как «одна прикладная система с разными исполняемыми файлами». Естественно, они могут использовать одну базу данных. Разумно используйте Schemata, чтобы изолировать различные функциональные области в одной базе данных.

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

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

Я думаю, что ответ на этот вопрос полностью зависит от ваших нефункциональных требований. Если вы разрабатываете приложение, которое однажды нужно будет развернуть на сотнях узлов, вам необходимо спроектировать свою базу данных так, чтобы при необходимости ее можно было масштабировать по горизонтали. Если, с другой стороны, это приложение будет использоваться несколькими пользователями и может иметь короткий срок годности, тогда ваш подход будет другим. Я недавно слушал состав группы о том, как устроена архитектура EBAY, http: //www.se-radio.net / podcast / 2008-09 / Episode-109-ebay039s-architecture-sizes-randy-shoup ​​, и у них есть база данных для каждого потока приложений, и они используют сегментирование для разделения таблиц по физическим узлам. Теперь их нефункциональные требования заключаются в том, чтобы система была доступна 24/7, была быстрой, могла поддерживать тысячи пользователей и не терять никаких важных данных. EBAY зарабатывает миллионы фунтов и поэтому может поддержать усилия, необходимые для разработки и поддержки.

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

В конце концов, вам нужно настроить и запустить вашу систему, а парни с заостренными волосами не станут волноваться о том, какой у вас крутой дизайн.

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

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

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

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

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

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

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

ПРИМЕР (предполагает вставку и обновление одной строки):

DECLARE @ref (datatype appropriate to your field)

SELECT @ref = refField FROM inserted

IF NOT EXISTS (SELECT *
FROM referenceserver.refDB.dbo.refTable
WHERE refField = @ref)
BEGIN
RAISERROR(...)
ROLLBACK TRAN
END

Для вставки и обновления нескольких строк вы можете присоединиться к таблицам в поле ссылки, но это может быть очень медленным.

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

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