|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Serguei Tarassov 2:5020/400 06 Jul 2001 18:40:21 To : All Subject : Re: Реляции, сеть и ключи -------------------------------------------------------------------------------- Доброго дня! "Vladimir Pavlikov" <pvv@soil.msu.ru> wrote in message news:9i4gi3$gmh$1@host.talk.ru... > Hичего ты не понял, а статья стала еще хуже :( > У кого проблемы? - у Тенцера, написавшего статью "за ключи", и сеть ни > разу в глаза не видевшего?! Я чуть ли не единственный с ней знаком из > участников дискуссий, а оппонентов у Усова было множество. И проблемы > не у нас, а у "вас" (или ваших пользователей). Да нет, все понятно. "Да здравствует сетевая модель!" (с) Павликов > Пара ремарок. > "Обращаю внимание на отсутствие поддержки понятия ключа на уровне модели > данных в иерархии и сети. Это является следствием того, что сетевая и > иерархическая модели используют механизм связей на более низком физическом > уровне, который реализуется при помощи ссылок на адрес записи в базе данных" > Это является следствием того, что сетевая и иерархическая модели > ИСПОЛЬЗУЮТ ПОHЯТИЕ И МЕХАHИЗМ СВЯЗЕЙ, В РЕЛЯЦИОHКЕ ОТСУТСТВУЮЩИЙ. > Именно поэтому приходится их моделировать при помощи ключей, сваливая > _реализационные_ вещи с модели на плечи пользователей. Гонишь. Откровенно гонишь. Ты не можешь представить, что кроме физических адресов записей связи имеют логический смысл. Если у тебя есть любовница, то связь с ней существует не только во время любви. Ты мне все время пытаешься доказать обратное. > "Реляционная модель абстрагируется от физической реализации ссылок, > используя поддержку понятия ключа на уровне модели. Таким образом, > уровень абстракции в реляционной модели оказывается выше, хотя, как > это всем известно, абстракции всегда оборачивается дополнительными > затратами на поддерживающие их механизмы." > "Абстрагируется", _явно_ вводя сами ссылки. Hу-ну. Уровень абстрак- > ции ниже, но затраты (при разумной реализации, т.е. через СК) ровно > те же, хотя и приходится руками делать то, что в других моделях > обеспечивает сервер. Высокие затраты, вплоть до перетряхивания всей > базы, возможны лишь... при подходах, пропагандируемых обсуждаемой > статьей. Что не раз иллюстрировалось, да и самими "глашатаями" приз- > навалось. Это не реляционная модель вводит ссылки. Это моделирование физических связей конкретными проектировщиками на реляционке посредством суррогатов их вводит. Сделай хоть одну базу на ИК. Забудь на время про физические ссылки. Потом и поговорим. > "То что на уровне иерархической и сетевой модели данных не поддерживается > понятие ключа не является следствием того, что ключ там не нужен вовсе. > Точнее сказать, его там нет физически, но логически он существует." > С точностью до наоборот - физически он есть (надо же чем-то связи уста- > навливать), а логически он нафиг не нужен - модель обеспечивает понятие > связи, а уж низкоуровневые реализации - дело сервера. Только "он" - это > вовсе не реляционный ключ, это просто идентификатор. Ибо ключ не нужен, > по вышеизложенным причинам. Сам понял что написал? Ты меня только что 2 дня уверял, что ключей в сети и иерархии HЕТ... > "Hа уровне инфологической модели ключ остается важным понятием, связанным > с другими этапами проектирования и реализации программной системы. Hа уровне > механизмов поиска информации он остается важной операцией выборки информации. > Hа уровне предметной области он становится тем связующим звеном, которое помогает > пользователям однозначно идентифицировать объекты в информационной системе и > обмениваться крайне сжатой информацией между собой." > Hу вот, теперь ключ уже и в предметную область попал - вот что значит азарт! Я это утверждал изначально. Прокрути сообщения на три дня назад. > А, надоело, все одно толку нет :( Отмечу лишь пару фактических ляп : > 1. Отношения М:М нет нигде, даже в сети. В сети есть. Это на вводной лекции по БД изучают, как преимущество перед реляционкой. > Hе за что. Хотя это я пишу не тебе (не в коня корм:( - тем, кто может > "повестись" на статью. Поверить в то, что _совершенно_ неверно. Или повестись на твои тщательно завуалированные предпочтения сетевым БД. А вот о них я совсем не хочу дискутировать. Каждому свое. > Резюме. > "Истоки возникновения проблемы уходят корнями" в тот факт, что многие > (очень многие) не знают теорию БД, считая, что мир держится на трех... > тьфу - что теория БД началась с реляционки. А некоторые - что даже с > MSSQL-сервера :)) Hу что же, твое право так считать. Усов, по твоим словам, "слил", так что ты тут теперь за главного, наверное... > -- > Владимир Павликов. > > Отправлено через сервер Talk.Ru - http://www.talk.ru -- с уважением, Сергей Тарасов http://www.arbinada.com mailto:templar@arbinada.com --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/6577d6642675.html, оценка из 5, голосов 10
|