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

Имаме две ситуации:

  1. Имаме сървър на база данни, който съдържа таблици с длъжности. Тези длъжности трябва да бъдат достъпни от база данни на друг сървър. Установихме свързана сървърна връзка и всичко работи добре. Проблеми: Не може да има референтна цялост на външен ключ, тъй като таблиците се съхраняват физически на друг сървър. Също така, всеки път, когато първият сървър бъде свален за поддръжка, той прекъсва приложенията на втория сървър, защото те зависят от него за свързаната сървърна връзка и данни.

  2. На друг сървър на база данни имаме база данни, която се използва за съхраняване на общи елементи от данни. Например, има таблица с щати и територии на САЩ, таблица с пощенски кодове и различни кодови таблици, използвани в нашите приложения. Проблем: Точно както по-горе, няма способности за референтна цялост. В допълнение, поддържането на сигурността и гарантирането, че потребителите, които имат достъп до базата данни на приложението, имат необходимия достъп до тази "обща" база данни, е досадно и отнема много време.

Въпросът ми е: Тъй като тези данни са само за четене за консумиращите приложения, можем ли да използваме репликация, за да разрешим този проблем? Можем ли да репликираме едната таблица със заглавия на длъжности от източника към целевия сървър/база данни и можем ли да направим същото за таблиците в „общата“ база данни (да ги репликираме във всяка база данни на приложението, която се нуждае от тях)? Мисля, че това ще елиминира горните проблеми, но дали ще бъде мъдър курс на действие или ще причини повече проблеми, отколкото решава?


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


Отговори (1)


Звучи сякаш се опитвате да разрешите прост проблем с много технологии. Ако искате да предоставите някакво референтно ограничение между таблици, свързани през свързан сървър, можете също да създадете тригери. Единствената причина да споменавам това е, че вашият сценарий посочва само няколко таблици.
Надявам се това да помогне

person John Hartsock    schedule 13.02.2010