|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Serguei Tarassov 2:5020/400 17 Jul 2001 15:37:16
To : All
Subject : Re: текстовые ключи
--------------------------------------------------------------------------------
Доброго дня!
"Tolik Tentser" <tt@katren.ru> wrote in message
news:9j09tg$jdp$1@news.nsk.su...
> > Именно так. Доступны, но излишни, поэтому пользователю эти данные (СК)
не
> > показывают. Hарушение сохраняется.
> Какому пользователю ????
> Бухгалтеру ?
> Да, не показывают
> Прикладной программе - еще раз повторяю - показывают
Таким образом, прикладная программа скрывает детали уровня _представления
данных_. Это значит, что его абстрактность нарушена, поэтому что-то скрывать
и приходится.
Все что я хочу от тебя выудить - не отказ от всеобщего использования СК -
нет. Только признание факта понижения абстрактности получаемой модели по
сравнению с моделью на ИК. Ради достижения других системных целей,
перечисленных у Усова или меня, а не просто так.
Послушай, если у тебя действительно в каждой таблице кроме СК есть ИК/ЕК, ты
не пробовал скрыть от программы это нарушение абстракции?
Легко ведь исправляется. Делаешь на каждую таблицу и запрос view, где все
поля, кроме СК. И работешь с ИК/ЕК. А связи по-прежнему держишь на СК :)
> > Другое дело, что эти "лишние" данные как-то системно обусловлены.
> > Далеко не для всех систем необходимость каскадных изменений являтся
> > критичной и, тем более, частой операцией.
> Это ты к чему ?
> Я про них еще ничего не говорил :-))))
> Hа вору шапка горит ?
Так это единственный серъезный аргумент, который можно рассматривать только
на уровне БД.
> Э-э-э-э ...
> Клиентское приложение перестало быть зависимым от данных ???
> Я тебя правильно понял ?
Правильно. Сначала много лет назад отказались от файлов, записей и индексов,
стали включаемый SQL (или аналог) в код пихать. Потом и вовсе обнаглели -
начали работать с неким ODBC-источником.
> > Относительно пользователя - он в общем случае совсем не знает, что такое
> БД.
> ... и ты на этом фоне обсуждаешь вопросы доступности ему ключей ?
Разумеется. Ключ - внемодельное логическое понятие. Идентификатор
экземпляра.
> > JOIN по неключевым атрибутам?
> Why not ?
> Случаи всякие бывают
> (с) Пятачок
> Вот как раз JOIN только и исключительно по ключевым аттрибутам означает
> отход от реляционной модели
Согласен, нет вопросов.
> > Если я тебя правильно понял, ты утверждаешь, что нарисовав логическую
> схему
> > без СК можно получить физическую с СК для реляционной модели?
> Само собой, более тогг, в критикуемой тобой (и наверно прочитанной тобой
?)
> статье даже рассказано как это делается :-Р
Расскажи тогда мне, как сделать схему в ER-модели и получить из нее
реляционную, не вводя СК на уровень ER. Hе получится не потому, что ER
плоха, а потому что реляционка более абстрактна, чем сеть.
> Что ты привязался к сетевой модели ?
> Смотри пример выше с JOIN T1 -> T3
> это уже совершенно не сетевая модель, а как раз реляционная
Гибридная ;-) Связи явно устанавливаешь. Пример, имеем 2 ключа экземпяров
(не СК, а ИК/ЕК), хотим их связать (1:М).
1. Ищем ID1 по ключу 1
2. Ищем ID2 по ключу 2
3. Связываем (проставляем в поле связи сущности1 значение ID2)
В сети:
1. Ищем ID записи по ключу 1
2. Ищем ID2 записи ключу 2
3. Связываем
> > Hе означает. Значит есть унифицированная обработка ядром. Сервис
получает
> > OID и что-то с объектом делает.
> Hу делает. Только HЕ ядро БД.
Естественно. Ядро прикладной системы.
> И какое вообще отношение имеет этот вопрос к каким бы то ни было ключам ?
Как системное обоснование для СК.
> --
> Bye ...
> Тенцер А.Л.
> tolik@katren.ru
> ICQ 15925834
--
с уважением,
Сергей Тарасов
http://www.arbinada.com
mailto:templar@arbinada.com
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
