|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Vladimir Pavlikov 2:5020/400 08 Aug 2001 16:30:13
To : All
Subject : Re: текстовые ключи
--------------------------------------------------------------------------------
Hello! "Serguei Tarassov" <templar@arbinada.com> wrote:
> Итак, имеем отношение "Люди" с уникальным атрибутом "ПИH-код" и связанные с
> ним М:1 "Улицы" с уникальным атрибутом "Код улицы". Оба атрибута уникальны в
> пределах города, репликация идет только внутри города между рапределенными БД.
> В каждом узле изменяется отношение "Люди" - новые рождаются, старые, к
> сожалению, помирают, для остальных незначащие атрибуты могут уточняться,
> например, измениться адрес и, соотвественнно, улица проживания.
> Делаем простую одностороннюю репликацию из одного узла в другой.
> А. Реляционка.
> 1. Выбираем все изменившиеся кортежи из сущности "Люди".
> 2. Отправляем их в другой узел
И к каким улицам их "приписываем"? См. ниже.
> 3. Это все.
Увы, далеко не все. Улицы переименовываются, появляются новые, дробятся
и сливаются... Соответственно, такой подход не годится. С учетом того,
что люди выступают в качестве подчиненной сущности - начинать нужно с
первичной, т.е. с улиц. Причем - рекурсивно, т.е. обработав одну улицу -
обрабатываем всех связанных с ней людей, затем следующую улицу и т.д.
> Сеть.
> 1. Выбираем все изменившиеся записи типа "Люди".
> 2. Мы не можем просто отправить их на другой узел, так как связь с "Улицами"
> внутренняя, то есть поддерживается в БД данного узла.
> 3. Что делать?
Ровно то же самое. Разница лишь в том, что работать будем не с самой
связью, а с полученным через нее "ЕК". При использовании в реляцион-
ке суррогатов аналогия становится полной.
> P.S. Здесь аналогия с суррогатами проявляется в полной мере.
Совершенно верно, именно об этом я и писал. Попытка использовать сугубо
_внутренние_ вещи для решения _внешних_ задач абсолютно безграмотна, и
характеризует не модели, а их пользователей. А вот уникальный набор
_сущностных атрибутов_ (который в реляционке используется, _как_ ключ)
абсолютно внемоделен и либо есть, либо его нет. Есть или нет не в модели,
не в предметной области и не в задаче, повторюсь, а в базе :) Есть -
репликация возможна, нет - значит нет.
> Hо если в
> реляционке ты имеешь возможность динамически менять ключ (при репликации
> будет использован глобальный, возможно, составной), то в сети такого
> механизма нет.
Это неверно, причем дважды.
1. Динамически переустанавливать связь равным образом можно и в реляционке,
и в сети.
2. Составной "ключ", как "обеспечитель" и задач репликации, в частности - это
общий механизм, не относящийся ни к той, ни к другой модели, и равно применимый
в обеих. Отличия лишь в реализациях - в реляционке это может быть либо состав-
ной ключ (один), либо два форинкея. В сети - либо "двойная" связь, либо две
связи.
И - маленькое замечание. Указанного механизма нет ни там, ни там. В смысле -
в моделях отсутствуют, серверами не обеспечиваются. Что понятно - речь о
операции, выходящей за рамки БД. Hо - легко реализуются "руками", с использо-
ванием модельных механизмов.
Hапример, если ты имеешь в "Людях" и "Улицах" суррогат, то
> ничто не мешает тебе послать кортеж, в котором суррогат будет заменен на
> другой ключ - код улицы - связь в принимающем узле пойдет по нему.
Верно, но это очень частный случай. Годится в небольшой части "игрушечных"
БД. Универсальный механизм - рекурсия, о чем написано выше. Hекоторые слож-
ности есть лишь при работе с отношениями М:М иерархий. Hо они общие для
обоих моделей, и решаемы.
И последнее. Ты написал, что ответа на вопрос не увидел, поэтому формулирую
его отдельно и целиком:
_Hикаких_ различий при проведении репликации в двух моделях нет, ибо
проводятся они по одним и тем же данным - реальным свойствам реальных
экземпляров сущностей. Тут не могут быть использованы суррогаты (за
исключением случаев, когда они заранее "заточены" на использование
при репликации) и другие _внутренние_ механизмы БД, включая и иденти-
фикаторы (неважно чего - экземпляров или связей) уровня самой БД only
типа "номеров записей" и прочих "локальных гуидов".
Отличия могут быть лишь на уровне "трюков" использования специфик
(не столько моделей, сколько конкретных серверов) и при чисто внут-
ренних операциях по _подготовке_ данных перед проведением собственно
репликации. Что понятно, ибо любые выборки данных - операции внутрен-
ние, модельно- и серверо- зависимые.
Единственное, что могу добавить - на внешних операциях типа репли-
кации преимуществ у сети перед реляционкой нет - отсутствующие для
этого в обеих моделях механизмы одинаково, руками, и реализуются.
Либо "спецсредствами", если они у сервера есть, но это уже "совсем
другая история"(С).
--
Владимир Павликов.
Отправлено через сервер Talk.Ru - http://www.talk.ru
--- ifmail v.2.15dev5
* Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
