Чи варто використовувати одну базу даних на додаток або поділитися однією базою даних між кількома програмами [закрито]

У мене є кілька додатків, які використовують дані з одних і тих же джерел. Чи найкраща практика (або які плюси / мінуси):

• залишити дані в базах даних, якими користуються кілька додатків

  1. економить місце, оскільки потрібна лише одна база даних
  2. ускладнює індексацію, оскільки різні програми мають різні запити

• щодня імпортувати дані в бази даних за програмою

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

Я, можливо, залишив інші переваги / недоліки, будь ласка, перерахуйте їх, якщо такі є, а також як це робиться на вашому робочому місці?

Простір сьогодні дешевий, тому я б радив використовувати одну базу даних на додаток.

Обмін однією базою даних серед кількох додатків має деякі серйозні недоліки :

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

• Витрати на обслуговування та розробку можуть зрости : Розробка складніше, якщо додатку потрібно використовувати структури баз даних, які не підходять для вирішення задачі, але їх потрібно використовувати так, як вони вже є. Цілком ймовірно, що коригування однієї програми спричинить побічні ефекти для інших програм ("чому існує такий непотрібний тригер ??!" / "Нам більше не потрібні ці дані!"). Із однією базою даних для однієї програми вже важко, коли розробники не / можуть не знати всіх випадків використання.

• Адмініструванню стає складніше: який об’єкт належить до якої програми? Хаос зростає. Де я повинен шукати свої дані? Кому користувачеві дозволено взаємодіяти з якими об’єктами? Що я можу надати кому?

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

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

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

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

У мене колись була схожа ситуація. Моя проблема полягала в тому, щоб створити 3 програми, один для управління запасами, один для управління закупівлями та один для управління користувачами, тобто працівниками. Моя рекомендація - не ламати бази даних фізично за програмою або приєднуватися до них фізично за програмою. Швидше, логічне розділення ІМХО працює краще.

Наприклад, усі 3 програми, необхідні для роботи з інформацією про працівників. І системи інвентаризації, і закупівлі використовували однакову інформацію про товари та товарно-матеріальних цінностей.

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

Я також створив загальний інтерфейс для взаємодії з користувачами та товарами, який був окремим веб-додатком.

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

Якщо ці програми призначені для роботи з одних і тих же даних - наприклад, одного і того ж списку продуктів та клієнтів - тоді зберігайте базу даних разом. Ви нічого не отримуєте, відокремлюючи бази даних. Це суто "людська" проблема - для сервера його справедливі байти на диску. Це не хвилює, якщо його 1 або 100 баз даних. Але якщо ви їх розділите, вам доведеться мати справу з синхронізацією даних. Проблеми з індексацією, які ви піднімаєте, не є справжньою проблемою - ви витратили стільки ж часу процесора на підтримку індексів, якби розрядність була розбита.

Якщо продуктивність починає ставати проблемою, копіюйте db на декілька серверів, щоб збалансувати речі.

У вашій ситуації це може бути, а може і не варто, але підтримувати цілісність даних простіше за допомогою єдиної бази даних. Принаймні, у MS SQL Server ви не можете ввести іноземний ключ від однієї бази даних до іншої бази даних. Ви можете імітувати поведінку іноземних ключів за допомогою тригерів, але це не особливо елегантно.

Крім того, створення локальних копій даних може бути небезпечним, коли записи починають грати. Якщо в AppA і AppB є копія деяких спільних даних, а AppA оновлює їх, у AppB все ще будуть старі дані. Або вам доведеться налаштувати тригери для синхронізації даних.

Колись у мене було кілька веб-сайтів, які стали популярними з часом. Вони використовували окремі бази даних, здебільшого тому, що хостинг-провайдер дозволяв зберігати лише 1 Гб місця для зберігання. Але! Як тільки я випустив сервіс, який включав усі ці веб-сайти, мені почали робити транзакції між цими веб-сайтами, і найзручніший спосіб це зробити - це безперечно перемістити все в одну велику базу даних.

Тож я оптимізував структуру бази даних і видавив відповідні частини до цієї центральної бази даних, але все інше залишив.

Моя думка якось пов’язана з парадигмами ООП. Подібні дані потрібно зберігати разом, тому якщо ви створюєте різні програми, ви повинні використовувати для них різні бази даних.

У наведеному вище випадку використання загального db не вдалося уникнути, але пам’ятайте, що я також зберігав окремі таблиці в окремому db, які не є частиною загальних запитів.

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

Загалом, ви можете підтримувати загальну базу даних для загальних запитів, а також зберігати її для кожної програми.

Чи можете ви детальніше розповісти про архітектуру додатків?

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