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

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

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

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

Итак, основной вопрос: какой из двух подходов вы рекомендуете?

Спасибо,

Хорхе Варгас.

Изменить 1:

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

Изменить 2:

Ссылки на связанные вопросы:

Только второй имеет принятый ответ. Все еще не решили, что делать.

Ответ:

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

Я также использую триггеры и логические удаления, чтобы попытаться свести к минимуму число ID, которое я буду летать вокруг livin 'la vida loca без родителя. Усилия по разработке, необходимые для синхронизации баз данных, слишком велики, и выигрыш слишком мал (как вы все указали). Итак, я бы предпочел пробиться через осиротевшие записи.

Поскольку использование ORM и представлений было сначала предложено svinto, он получает правильный ответ.

Спасибо всем за то, что помогли мне с этим жестким решением.

Ответ 1

Это зависит, и ваши варианты немного отличаются в зависимости от базы данных и фреймворков, которые вы используете. Я бы рекомендовал использовать какой-то ORM, и вам не нужно так беспокоиться. В любом случае, возможно, вы могли бы поместить каждое приложение в свою собственную схему в базе данных, а затем либо ссылаться на общие таблицы по имени schemaname.tablename, либо создавать представления в каждой схеме приложения, а только SELECT * FROM schemaname.tablename, а затем кодировать это представление.

Ответ 2

Ни один из способов не выглядит идеальным

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

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

Ответ 3

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

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

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

Мои 2центы.

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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

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

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

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

ПРИМЕР (подразумевает однострочные вставки и обновления):

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

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

Ответ 8

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

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

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

Ответ 9

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

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