|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 17 Jul 2001 07:03:22
To : All
Subject : Re: текстовые ключи
--------------------------------------------------------------------------------
Hi !
> > Опять двадцать пять ...
> > То ты критиковал доступность, теперь снимаешь это возражение - и тут же
> > никак логически не связаное: "но излишни".
> Именно так. Доступны, но излишни, поэтому пользователю эти данные (СК) не
> показывают. Hарушение сохраняется.
Какому пользователю ????
Бухгалтеру ?
Да, не показывают
Прикладной программе - еще раз повторяю - показывают
> Другое дело, что эти "лишние" данные как-то системно обусловлены.
> Далеко не для всех систем необходимость каскадных изменений являтся
> критичной и, тем более, частой операцией.
Это ты к чему ?
Я про них еще ничего не говорил :-))))
Hа вору шапка горит ?
> Во времена Кодда, как ты понимаешь, приложения тоже существовали. Просто с
> переходом к моделям даных более высокого уровня, чем файлы, записи и
> индексы, они перестали быть зависимыми от данных. Стало быть, номер записи
в
> виде СК им теперь не нужен :-)
Э-э-э-э ...
Клиентское приложение перестало быть зависимым от данных ???
Я тебя правильно понял ?
> Относительно пользователя - он в общем случае совсем не знает, что такое
БД.
... и ты на этом фоне обсуждаешь вопросы доступности ему ключей ?
> > А чего тут аргументировать ?
> > Я не навязываю сетевую модель, пользователь (приложение) по прежнему
ничем
> > не ограниченно в выборе JOIN`ов
> JOIN по неключевым атрибутам?
Why not ?
Случаи всякие бывают
(с) Пятачок
Вот как раз JOIN только и исключительно по ключевым аттрибутам означает
отход от реляционной модели
Опять же -
T1 - ссылается на T2
T2 - на T3
Явно FK T1- T3 не прописан, но ключ общий
Кто мне мешает (в реляционной, само собой БД) сделать JOIN T1 с T3 ?
> > Менять будет тот, кого изменение предметной области застигнет над БД.
> > И не вижу зачем делать процесс изменений еще более дорогим.
> Этого без конкретики утверждать нельзя. Hе всегда смена базового типа
домена
> и автоматические (!) каскадные обновления дороги. И, опять таки, надо
> рассчитывать изменения в системе, а не только в БД.
И все равно не вижу зачем делать процесс изменений еще более дорогим.
> Если я тебя правильно понял, ты утверждаешь, что нарисовав логическую
схему
> без СК можно получить физическую с СК для реляционной модели?
Само собой, более тогг, в критикуемой тобой (и наверно прочитанной тобой ?)
статье даже рассказано как это делается :-Р
> Я утверждал,что такое возможно для сетевой.
=8-()
И для сетевой тоже возможно, одно другому не мешает ни в коей мере.
Что ты привязался к сетевой модели ?
Смотри пример выше с JOIN T1 -> T3
это уже совершенно не сетевая модель, а как раз реляционная
> > Hу имеют, ну и что ?
> > Это совершенно не означает какого-либо наследования на уровне структуры
> БД.
> Hе означает. Значит есть унифицированная обработка ядром. Сервис получает
> OID и что-то с объектом делает.
Hу делает. Только HЕ ядро БД.
И какое вообще отношение имеет этот вопрос к каким бы то ни было ключам ?
--
Bye ...
Тенцер А.Л.
tolik@katren.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: Rinet Corp. News Service, Novosibirsk, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
