Кілька V / s декількох баз даних

Я створив цей веб-додаток (php & mysql), який зберігає інформацію для різних організацій (наразі близько 20 клієнтів).

Поточний сценарій зберігає інформацію, пов'язану з клієнтом, в окремих базах даних, тому існує 20 клієнтських баз даних та 1 головна база даних.

Однією з головних переваг тут є те, що по мірі того, як кожен клієнт db є ізольованим, нумерація артефактів клієнта (звітів, аудитів) тощо проводиться впорядкованості; що дає нашим клієнтам відчуття безпеки.

Кожна БД має приблизно 15 таблиць, а найбільше рядків у таблиці - приблизно 2000. Це, як очікується, може бути збільшено до 5000 записів.

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

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

Звичайно, деякі важливі проблеми, які виникають, такі:

а. Підтримуючи послідовність артефактів (це можна вирішити, створивши додатковий довідковий ключ) b. Швидкість та продуктивність (у такому випадку я можу створити індекси для прискорення речей) c. Безпека: цим керуватиме як кожен запит, який отримує інформацію про клієнта. також буде відслідковувати їх client_id

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

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

Дякую за вашу пораду.

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

Програми єдиної БД:

1. Оновлення програмного забезпечення та виправлення помилок простіше.
2. Легко керувати та звітувати про всі дані клієнта.
3. Оновлення даних стає простішим.
4. Легко створити модульну функціональність, яку хоче 1 клієнт, вимкніть, якщо вона відключена для інших клієнтів, а потім увімкніть її, коли вони захочуть її в майбутньому.

Конфігурація єдиної БД:

1. Цілісність даних. У нас було 2 або 3 випадки, коли користувачі 1 банку бачили дані іншого банку. Це був кошмар. Тим більше, що користувачі сайту були не просто працівниками банку, а фактичними обліковими записами клієнтів банку! Це, безумовно, найбільша проблема з 1 базою даних
2. Експорт даних клієнтів - Коли ми мали це зробити, зазвичай це не було великою справою. У вас виходить 1 таблиця, в якій є всі клієнти, і ви відключите цю таблицю, щоб отримати дані клієнта.

Програми декількох БД:

1. Не викликає занепокоєння перехресне забруднення даних клієнтів або їх порушення
2. Експорт даних клієнтів просто мертвий.

Con з декількох БД:

1. Оновлення та виправлення помилок - Це був справжній кошмар. Якщо у вас є 20 клієнтів на 20 різних базах даних, ви швидко натрапите на випадок, коли 1 клієнт хоче виправити помилку, а інший вважає, що помилка є функцією або не хоче ризикувати оновленням. Крім того, у вас є випадки, коли 1 клієнт хоче покращити гру, але інші клієнти цього не роблять. Коли це станеться, ваші бази даних почнуть розходитися. Раптом вам доведеться оновити клієнтів 1-15 з 1 сценарієм 16-19 з іншим і 20 з третім. Ми побачили, що це стає такою проблемою, що виправлення помилок займе 15-20 разів довше для компанії, яку ми придбали, ніж для нас, оскільки їм довелося запустити всі тести для кожного клієнта та обробити спеціальний код кожного клієнта. Ефективно, їм була потрібна нова особа підтримки для кожного нового клієнта,
2. Управління БД - Коли ви потрапляєте до великої кількості клієнтів, що керують усіма базами даних, стає справжнім клопотом. Вам, без сумніву, потрібно буде більше часу для DBA для управління ними.

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

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

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

Якщо ви хочете порівняти дані між клієнтами, то вам слід зробити це окремо.

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

Єдина причина, в якій я не мав би індивідуальної бази даних для кожного клієнта, це якщо у вас є 100 або 1000 клієнтів / баз даних. Це може бути дуже волохатим в управлінні, включаючи внесення змін до бази даних чи щось робити у всіх базах даних. Дії, що відбуваються у великій кількості безлічі баз даних, також можуть бути повільними, оскільки вам потрібно відкрити (і тому закрити) стільки таблиць.

Але окрім цього випадку, я думаю, що кілька баз даних краще.

Однією з переваг, яка може бути не важливою, але може бути корисною, є те, що кожен клієнт отримує власні послідовні ідентифікатори (замість того, щоб, можливо, пропускати купу, оскільки інший клієнт додав записи).

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

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

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

По дорозі простіше масштабувати одну базу даних (розділення, апаратне забезпечення, загострення тощо), ніж це зробити для 100 баз даних.

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

Щоб додати до перелічених до цього часу професіоналів:

Про множина баз даних:

1. Уникають проблеми блокування; у нас є бази даних, де клієнти можуть викликати зміни DDL в деяких таблицях. Для більших таблиць (> 2м записів) це блокує таблицю протягом значного часу. Єдиними людьми, які перебувають у невигідному становищі, є власні користувачі, тому це на зразок прийнятного.

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

Мінуси:

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

Успіхів у виборі!

Я знаю, що ви вже обрали відповідь, але, схоже, є ще одне рішення, яке не було запропоновано:

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

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

Це щось найкраще з обох світів.

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