Это хорошая идея использовать синонимы, чтобы избежать создания дубликата таблицы?

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

Будет ли лучшей идеей удалить Usersтаблицу из баз данных 2 и 3 и заменить ее Synonymточкой, указывающей на базу данных 1?

Вот плюсы / минусы, которые я могу придумать:

Pros

• Более простое обслуживание. Может обновлять пользователей в одном месте вместо 3
• Идентификаторы пользователей будут совпадать между базами данных (важно, поскольку многие дополнительные приложения основаны на идентификаторе пользователя)

Cons

• Не думайте, что это стандартная процедура, поэтому может сбить с толку
• Пользователи должны иметь одинаковые настройки между базами данных
• (Из ответа gbn ниже). Если база данных 1 выйдет из строя , базы данных 2 и 3 также будут недоступны. Также существует потенциальная проблема несовместимости данных в случае восстановления.

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

Почему у вас есть 3 базы данных с одинаковыми пользователями?

Что произойдет, если одна база данных выйдет из строя сейчас?

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

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

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

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

Правда, с этой идеей «канонической пользовательской таблицы» - используете ли вы синонимы или синхронизируете данные - вы не можете изменять пользователей во время неактивной базы данных, но мне это кажется приемлемым. Исправьте проблему и поднимите ее! Один источник, одно место для редактирования, одно исправление, если оно сломано. При синхронизации все остальные базы данных имеют временные копии, с которыми они могут работать, но без редактирования. Минимизация дублирования данных в разных системах является большой и полезной целью. Серьезной проблемой является ввод одних и тех же данных в трех местах, поэтому сделайте все возможное, чтобы устранить это.

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

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

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

Отсутствует "Кон"

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

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

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

Так что не делай этого ...

Соответствующий ответ на dba.se: Критерии принятия решения о том, когда использовать схему не-dbo против новой базы данных о «ссылочной целостности базы данных» после восстановления

В зависимости от вашей платформы базы данных, другой вариант - удалить таблицы в базах данных 2 и 3 и заменить их материализованными представлениями таблицы в базе данных 1.

Pros

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

Cons

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

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

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

Я бы создал 4-ю БД, в которой хранится общая информация о пользователе. Создайте Synonymsили Viewsв каждом из других БД, указывающих на БД пользователей.

Наконец, я бы создал таблицу расширений (таблицу с отношением One-one с «UserDB.Usertable») в каждом из 3-х существующих БД, которые содержат пользовательские данные, специфичные для этого приложения.

Изменить: на основе комментария ниже

В этом случае заставьте First db выступать в качестве главной таблицы пользователей. Synonymsи таблица расширения в каждом из других БД.

Важное примечание : При таком подходе, если ваше первое приложение выходит из строя, остальные два рушатся вместе с ним! Убедитесь, что все понимают этот недостаток.