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