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