Репликация для поддержания целостности данных

У нас есть две ситуации:

  1. У нас есть сервер базы данных, содержащий таблицы названий должностей. Эти названия должностей должны быть доступны из базы данных на другом сервере. Мы установили подключение к связанному серверу, и все работает нормально. Проблемы: не может быть ссылочной целостности внешнего ключа, потому что таблицы физически хранятся на другом сервере. Кроме того, всякий раз, когда первый сервер отключается для обслуживания, это приводит к нарушению работы приложений на втором сервере, поскольку они зависят от него в отношении соединения и данных связанного сервера.

  2. На другом сервере базы данных у нас есть база данных, которая используется для хранения общих элементов данных. Например, в наших приложениях есть таблица штатов и территорий США, таблица почтовых индексов и различные таблицы кодов. Проблема: Как и выше, нет возможности ссылочной целостности. Кроме того, поддержание безопасности и обеспечение того, чтобы пользователи, имеющие доступ к базе данных приложения, имели необходимый доступ к этой «общей» базе данных, утомительно и отнимает много времени.

Мой вопрос: поскольку эти данные доступны только для чтения для приложений-потребителей, можем ли мы использовать репликацию для решения этой проблемы? Можем ли мы реплицировать одну таблицу названий должностей из источника на целевой сервер / базу данных, и можем ли мы сделать то же самое для таблиц в «общей» базе данных (реплицировать их в любую базу данных приложения, которая в них нуждается)? Я думаю, что это устранило бы вышеуказанные проблемы, но будет ли это разумным курсом действий или это вызовет больше проблем, чем решит?


person DCNYAM    schedule 05.02.2010    source источник


Ответы (1)


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

person John Hartsock    schedule 13.02.2010