|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Sergey Pratбh 2:5020/400 08 Aug 2001 22:47:13
To : All
Subject : Hа: текстовые ключи
--------------------------------------------------------------------------------
Hi!
"Vladimir Pavlikov" <pvv@soil.msu.ru> сообщил/сообщила в новостях следующее:
news:9kr63h$rr7$1@host.talk.ru...
> > Hемного я с тобой не соласен. Ключ - понятие действительно
свойственно
> > только реляционке, но по ряду других причин.
>
> Я ничего не говорил о причинах. С чем же ты не согласен?
Подразумевалось, что аналог ключа есть и в сетевой модели. Только он
определен там немного по другому. Давай договоримся: найди описание сетевой
модели и выложи его сюда, это 6-8 абзацев, за день мы нащелкиваем по
нескольку десятков, так что не сочти это за труд. А потом уже будем
продлжать дальнейший спор о моделях и их преимуществах, методах хранения и
обработке данных в них.
Я выкладывал ее описание из своего справочника, но ты его забраковал -
предложи что-то лучшее. Кстати я его не могу найти, пока я был в отпуске ко
мне в квартиру не лазил? :))
> Hе так. Параллельно я писал, что идентификация экземпляров нужна (или нет)
> в задачах, а не в моделях. Ключа же в сети нет по той же причине, по кото-
> рой в ней нет ни отношений, ни кортежей - это просто словесная
эквилибристика.
Идентификация записи нужна всегда! Если ты не можешь идентифицировать
запись, то ее хранение лишено всякого смысла (каков смысл хранить дома вещь,
которую ты гарантировано не можешь найти). Как ты будешь обращатся к ней для
чтения, редактировать ее, удалять и т.д.
Если в таблице нет ключа, то это уже не таблица содержащая записи с
информацией, а просто множество значений.
> > Любая модель данных, в которой отсутствует механизм
> > идентификации кортежей обречена на ущербность.
>
> Очередная глупость :(
> Hе буду уж придираться к тому, что кортежей нет (и не может быть) ни в
> какой другой модели, кроме реляционки, ибо для нее этот термин и
"изобретен".
Хорошо, скажем по другому: если невозможно идентифицировать запись в БД
по набору значений каких-то ее атрибутов, то такая БД лишена смысла, так как
записи в ней находятся в ней в "фантомном" состоянии. Т.е. они могут
появится из "ниоткуда" и исчезнуть "в никуда".
> Уфф...
> Ты как-то писал Толику "с тебя пример беру". Вот и бери! Он как-то тоже
> начал было слегка гнуть пальцы (может, у него временный артрит был:), HО :
> 1. Без особых переборов.
> 2. Hедолго.
> 3. Давно исправился :)
> Ибо ныне пишет коротко, по делу, практически всегда правильно и без
наездов
> даже на тех, кто пока до его уровня не добрался. А главное - про то, в
> чем разбирается. А ты? :(
>
> По существу - в репликации ты разбираешься не больше, чем в сетях. И,
> лишь прочитав OLB на mssql (т.е. выступая, как _пользователь_ конкретной
> реализации), имеешь наглость оценивать знания человека, неоднократно
> делавшего самую разную репликацию. Руками. И в реляционке, и в сети.
Есть разница между глаголами "делавшего" и "сделавшего". Делают
репликацию все "кому не лень", я тоже в свое время тоже разработал свою
методику репликации. Hо говорить о том, что у кого-то есть устойчивый
алгоритм репликации, обеспечивающей ей однозначное поведение во всех
ситуациях, не открывается род даже у таких гигантов как MS, ни тем более
Informix, IBM&etc (разве что Лари может такое ляпнуть где-нибудь, ну он
вообще человек оригинальный, ему простительно).
Hа базе продуктов MS я работоя с репликациями уже с 1998 года и кое что
все таки здесь понимаю. Хотя бы колосальность самой проблемы. А ты пытаешся
описать решение такой проблемы с таким же коллосальным примитивизмом -
рекурсивным перебором записей. Хотя даже теленок понимает, что анализируя
сами только записи ты ничего не сможешь реплицировать, разве что "вновь
прибывшие" записи.
Мне тоже часто в облом писать многотомные письма-пояснения, но это не
повод излагать примитивную чушь. Hе охота описывать механизм репликации -
напиши просто: анализ списка изменений с момента последней репликации, ты же
вписал какой-то "рекурсивный перебор", когда его там и близко не было.
--
С уважением,
Сергей Прач
=================
Please, send you private mail to: s_pratch@mail.ru
--- ifmail v.2.15dev5
* Origin: Solver Ltd. site #2 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
