Должен ли я использовать одну базу данных для одного приложения или использовать одну базу данных для нескольких приложений [закрыто]

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

• оставить данные в базах данных, совместно используемых несколькими приложениями

  1. экономит место, так как нужна только одна база данных
  2. усложняет индексацию, так как разные приложения имеют разные запросы

• ежедневно импортировать данные в базы данных для приложений

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

Возможно, я пропустил другие преимущества / недостатки, перечислите, если таковые имеются, а также как это делается на вашем рабочем месте?

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

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

• Чем больше приложений используют одну и ту же базу данных, тем выше вероятность того, что вы столкнетесь с узкими местами в производительности и не сможете легко масштабировать нагрузку по желанию . Базы данных SQL на самом деле не масштабируются. Вы можете купить большие машины, но они плохо масштабируются в кластерах!

• Затраты на обслуживание и разработку могут увеличиться : разработка становится сложнее, если приложению необходимо использовать структуры базы данных, которые не подходят для поставленной задачи, но должны использоваться, поскольку они уже присутствуют. Также вероятно, что настройки одного приложения будут иметь побочные эффекты для других приложений («почему существует такой ненужный триггер ??!» / «Нам больше не нужны эти данные!»). Уже сложно с одной базой данных для одного приложения, когда разработчики не знают / не могут знать все варианты использования.

• Администрирование становится сложнее: какой объект принадлежит какому приложению? Хаос нарастает. Где я должен искать свои данные? Какому пользователю разрешено взаимодействовать с какими объектами? Что я могу подарить кому?

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

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

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

Редактировать: Я хотел бы отметить, однако, что, как упомянул @Saeed, если вы можете инкапсулировать манипуляции с данными в общедоступном сервисе, то проще совместно использовать одну базу данных с несколькими приложениями. Пока вам не нужен необработанный доступ, это очень хороший подход.

У меня была похожая ситуация однажды. Моя задача состояла в том, чтобы создать 3 приложения, одно для управления запасами, одно для управления закупками и одно для управления пользователями, то есть сотрудниками. Я не рекомендую физически разбивать базы данных для каждого приложения или объединять их физически для каждого приложения. Скорее ИМХО логическое разделение работает лучше.

Например, все 3 приложения должны были работать с информацией о сотрудниках. И системы инвентаризации, и системы закупок использовали одну и ту же информацию о товарах и инвентарных позициях.

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

Я также создал общий интерфейс для взаимодействия с пользователями и товарами, который был отдельным веб-приложением.

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

Если эти приложения предназначены для работы с одними и теми же данными - например, с одним и тем же списком продуктов и клиентов - сохраните базу данных вместе. Вы ничего не получаете, разделяя базы данных. Это чисто «человеческая» проблема - для сервера это просто байты на диске. Это не волнует, если его 1 или 100 баз данных. Но если вы разделите его, вам придется иметь дело с синхронизацией данных. Возникающие у вас проблемы с индексацией не являются реальной проблемой - вы бы потратили столько же процессорного времени на поддержание индексов, если бы базы данных были разделены.

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

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

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

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

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

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

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

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

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

Можете ли вы подробнее рассказать об архитектуре вашего приложения?

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