Чи корисно використовувати синоніми, щоб уникнути створення повторюваної таблиці?

У нас є 3 копії точно такої ж бази даних. У всіх 3 базах даних є Usersтаблиця, і Користувач завжди буде існувати у всіх 3 базах даних з точно однаковими налаштуваннями. Щоразу, коли ми хочемо додати або відредагувати користувача, ми маємо оновити 3 бази даних.

Було б кращою ідеєю видалити Usersтаблицю з баз 2 та 3 та замінити її на, Synonymщо вказує на базу даних 1?

Ось плюси та мінуси, про які я можу придумати:

Плюси

• Легше обслуговування. Може оновлювати користувачів в одному місці замість 3
• Ідентифікатори користувачів відповідатимуть базам даних (важливо, оскільки багато додатків базуються на UserId)

Мінуси

• Не думайте, що це стандартна процедура, тому це може заплутати
• Користувачі повинні мати однакові налаштування між базами даних
• (З відповіді gbn нижче) Якщо Database 1 колись знизиться, Database 2 і 3 також будуть недоступні. Також існує потенційна проблема з тим, що дані будуть непослідовними у випадку відновлення

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

Чому у вас є 3 бази даних з тими ж користувачами?

Що станеться, якщо одна база даних зараз знищиться?

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

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

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

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

Щоправда, з цією ідеєю "канонічної таблиці користувачів" - чи використовуєте ви синоніми чи синхронізуєте дані - ви не можете змінювати користувачів під час БД користувача, але мені це здається нормальним. Вирішіть проблему та вирішіть її! Одне джерело, одне місце для редагування, одне, що потрібно виправити, якщо воно порушено. Під час синхронізації всі інші бази даних мають тимчасові копії, з яких можна працювати, але без редагування. Мінімізація дублювання даних у всіх системах є великою і корисною метою. Введення одних і тих же даних у трьох місцях є серйозною проблемою, тому зробіть усе можливе, щоб усунути це.

Щоб вирішити більше ваших коментарів, якщо ваші ідентифікатори користувачів відрізняються у всіх ваших програмах, вам слід серйозно розглянути запланований час роботи для двох нових баз даних, щоб синхронізувати їх з основною (задайте окремий запитання, якщо вам потрібні ідеї про те, як це досягти, що хитро, але насправді НЕ ТРУДНО).

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

Одним із додаткових завдань щодо використання синонімів є те, що ви більше не зможете мати належних FK-користувачів для користувачів у кожній базі даних.

Не існує "Кон"

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

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

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

Отже, не робіть цього ...

Відповідна відповідь на dba.se: Критерії прийняття рішення про те, коли використовувати схему без dbo порівняно з новою базою даних про "цілісність референс-бази даних" після відновлення

Залежно від платформи вашої бази даних, ще одним варіантом є видалення таблиць у базах даних 2 та 3 та заміна їх матеріалізованими поданнями таблиці в базі даних 1.

Плюси

• Легше обслуговування (даних)
• Збіг ІД
• Недостатки не впливають на інші бази даних (принаймні, поки не потрібно внести зміни)
• Будь-яка база даних може бути використана для відновлення таблиці.

Мінуси

• Дані актуальні лише як графік оновлення.
• Якщо визначення таблиці зміниться, то, можливо, знадобиться також зміни, що впорядковані представлення.

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

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

Я б створив 4-ту БД, яка зберігає загальну інформацію про користувача. Створіть Synonymsабо Viewsв кожному з інших Dbs вкажіть на БД користувачів.

Нарешті, я створив би таблицю розширень (таблицю із взаємозв'язком один на один із "UserDB.Usertable") у кожному з 3 існуючих dbs, що містить дані користувачів, специфічні для цього додатка.

Редагувати: На підставі коментаря нижче

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

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