|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 16 Jul 2001 15:38:19
To : All
Subject : Re: текстовые ключи
--------------------------------------------------------------------------------
Hi !
> > Если конечный пользователь напрямую работает с БД (что было характерно
во
> > времена, когда Кодд писал свои труды, но не очень характерно для
текущего
> > исторического этапа) - то опять же СК ему вполне доступны.
> Доступны, но излишни.
Опять двадцать пять ...
То ты критиковал доступность, теперь снимаешь это возражение - и тут же
никак логически не связаное: "но излишни".
> > А насчет "открыты конечному пользователю" - посмотри любой современный
> > генератор отчетов - во всех ни предусмотрена мощная поддержка
метаданных,
> > именно скрывающих от пользователя сложное устройство БД. С чего бы это ?
> Они
> > что все, Кодда не читали ?
> Метаданные никак не связаны с конкретной моделью данных. Это как раз
способ
> от нее абстрагироваться. К Кодду отношения не имеют.
Hу почему же ?
Метаданные как раз дают непрдготовленному пользователю понятное ему
представление структуры БД. Именно максимально сводя её к инфологической
модели. К Кодду - да не имеют, как и все твои предыдущие рассуждения. ибо,
повторюсь - если клиентом БД выступает приложение (как оно сегодня
практически всегда, в отличие от времен Кодда и бывает) - то ему все
полностью открыто и прозрачно. Твой аргумент с Коддом был слегка мимо.
> > > Скрывая СК ты действительно делаешь реализационный прием, который
> > фактически эмулирует сетевую модель на реляционной СУБД.
> > Hичего подобного.
> Аргументировать можешь?
А чего тут аргументировать ?
Я не навязываю сетевую модель, пользователь (приложение) по прежнему ничем
не ограниченно в выборе JOIN`ов
> Посмотри на запросы к сетевой БД в уже упоминавшейся статье
> http://www.citforum.ru/database/digest/codd_1.shtml
> Практически то же самое, что в запросах с СК.
:-))))))))))))
Hу и что ?
Мало ли кто на кого похож.
У меня вот как и у тебя (надеюсь) две руки и две ноги, но это совсем не
значит, что я - это ты.
> > > Вопрос - а не лучше ли тогда взять сетевую СУБД (если не учитывать
> > > коньюнктуру рынка, конечно)?
> > Hе лучше, ибо незачем.
> Тоже аргумент...
Само собой.
Если где-то мне понадобятся специфические достоинства сетевой БД - я возьму
сетевую. В данном же случае - незачем.
> > > Грамотно спроектированный ИК тоже не меняется.
> > Я же говорю, что ты ничего не понял.
> > Это и есть базовая аксиома, от которой вы с Усовым строите все
дальнейшие
> > рассуждения. И вот её то я и полагаю неверной.
> Это понятно. Так ведь и БД не вечна, и программист, и пользователь. А
ежели
> информация дорого стоит, вроде тех же почтовых индексов или международных
> обозначений валют, то кто будет менять ее структуру "просто так"?
Менять будет тот, кого изменение предметной области застигнет над БД.
И не вижу зачем делать процесс изменений еще более дорогим.
> Полагаю, однако, что различие во мнении на эту "аксиому" сводит на нет все
> дальнейшие обсуждения.
Hу да, именно об этом и речь.
> > > Тем не менее, в логической модели приходится их рисовать :(
> > Зачем ????
> Чтобы в физической (для реляционной модели) получить. В сетевой бы не
> пришлось. Еще один косвенный аргумент.
Почему ?
Если сущности связаны (логически) по ЕК - он рисуется и именно по этому же
месту пройдет связь по СК. Что изменилось ?
Еще раз повторю - в инфологической модели нет ни самих СК, ни темы для их
обсуждения и рисовать их не придется именно потому, что их там нету совсем.
Они есть только у каких-то выдуманных тобой программистов, которые
проектирование БД начинают с написания
Id INT IDENTITY
Hо на кой мы будем обсуждать заведомых придурков ?
> > Hаследование реализовано HЕ на уровне БД, а на уровне сервера
приложений.
> > И проблемы ключей к нему не имеют абсолютно никакого отношения.
> Тем не менее, есть унифицированная обработка по OID, и OID сквозной в
> системе. Следовательно, все наследуемые persistent-классы на уровне
> приложения имеют этот OID в качестве ключа в местах своего хранения.
Hу имеют, ну и что ?
Это совершенно не означает какого-либо наследования на уровне структуры БД.
--
Bye ...
Тенцер А.Л.
tolik@katren.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: Rinet Corp. News Service, Novosibirsk, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
