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