|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Serguei Tarassov 2:5020/400 08 Aug 2001 21:08:15
To : All
Subject : Re: текстовые ключи
--------------------------------------------------------------------------------
Доброго дня!
"Vladimir Pavlikov" <pvv@soil.msu.ru> wrote in message
news:9krb9m$nri$1@host.talk.ru...
> И к каким улицам их "приписываем"? См. ниже.
"Приписываем" по месту изменения записи о человеке. Меняется только его
атрибут - внешний ключ улицы.
> > 3. Это все.
> Увы, далеко не все. Улицы переименовываются, появляются новые, дробятся
> и сливаются... Соответственно, такой подход не годится. С учетом того,
> что люди выступают в качестве подчиненной сущности - начинать нужно с
> первичной, т.е. с улиц. Причем - рекурсивно, т.е. обработав одну улицу -
> обрабатываем всех связанных с ней людей, затем следующую улицу и т.д.
Именно - все. Я не стал усложнять задачу, чтобы показать на одном и том же
примере простоту решения на реляционке и отсутствие таковой в сети.
Hа практике, конечно, и улицы меняются, но не меняются их
идентификаторы-ключи, которые в данном случае централизованно распределяются
муниципальными властями.
> > Сеть.
> Ровно то же самое. Разница лишь в том, что работать будем не с самой
> связью, а с полученным через нее "ЕК". При использовании в реляцион-
> ке суррогатов аналогия становится полной.
Вот и начинается самое интересное. В сети тебе придется кроме пересылки
измененной записи о человеке пересылать также и ключ связанной с ним
записи - улицы. Hеприятное усложнение даже в таком простом примере.
> Совершенно верно, именно об этом я и писал. Попытка использовать сугубо
> _внутренние_ вещи для решения _внешних_ задач абсолютно безграмотна, и
> характеризует не модели, а их пользователей. А вот уникальный набор
Здесь я с тобой согласен.
> _сущностных атрибутов_ (который в реляционке используется, _как_ ключ)
> абсолютно внемоделен и либо есть, либо его нет. Есть или нет не в модели,
> не в предметной области и не в задаче, повторюсь, а в базе :) Есть -
> репликация возможна, нет - значит нет.
А здесь - нет.
Функциональное требование - будет система распределенной или
централизованной - выдвигается на самых ранних стадиях создания системы.
Где-то между требованиями заказчика и их анализом.
Ты предлагаешь уже на этой стадии опуститься на уровень даталогической схемы
и сказать заказчику: "Репликация невозможна, так как у вас нет
ключей-идентификаторов"?
> Это неверно, причем дважды.
> 1. Динамически переустанавливать связь равным образом можно и в
реляционке,
> и в сети.
Только в сети для этого нужна лишний артефакт - связь. Это я по аналогии с
твоим мнением о "лишнем" ключе :) И лишние накладные расходы при реализации
модели.
Ты не будешь спорить, что переустановить связи для нескольких сотен тысяч
записей - быстрая операция?
> 2. Составной "ключ", как "обеспечитель" и задач репликации, в частности -
это
> общий механизм, не относящийся ни к той, ни к другой модели, и равно
применимый
> в обеих. Отличия лишь в реализациях - в реляционке это может быть либо
состав-
> ной ключ (один), либо два форинкея. В сети - либо "двойная" связь, либо
две связи.
Таким образом понятия ключа и в сети оказывается вовсе не лишним, а
наоборот, единственным артефактом, обеспечивающим возможность поддержки
распределенной БД.
И наверное, ты не станешь возражать, что хотя бы по этой причине знать о
ключах необходимо еще на уровне инфологического моделирования. Чтобы не
лажануться на более поздней стадии реализации системы.
> Единственное, что могу добавить - на внешних операциях типа репли-
> кации преимуществ у сети перед реляционкой нет - отсутствующие для
> этого в обеих моделях механизмы одинаково, руками, и реализуются.
И в этом тоже не соглашусь.
Если реляционная схема построена на Коддовских принципах и на ИК/ЕК, то
репликация проходит без ручных операций и дополнительного программирования.
Математика такой репликации формальна и описывается только реляционными
операциями, то есть допускается моделью.
Разумеется, не все случаи в жизни к этому можно свести, это понятно.
Hо в сети это невозможно в принципе из за _модельных_ ограничений.
> --
> Владимир Павликов.
--
с уважением,
Сергей Тарасов
http://www.arbinada.com
mailto:templar@arbinada.com
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
