|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Vladimir Pavlikov 2:5020/400 04 Jul 2001 13:53:45
To : All
Subject : Re: текстовые ключи
--------------------------------------------------------------------------------
Hello! "Serguei Tarassov" <templar@arbinada.com> wrote:
> > Ответь мне на вопрос : нафига тебе при построении _модели_ искать
> > отдельные экземпляры? Их вообще в модели нет. Они потребуются потом,
> > при эксплуатации, именно для этого реализации и нужны ключи. Причем
> > _любая_ имеет механизмы удобного их создания :)))
> Обязательно вводится. Если нет ключа, то не может быть и никаких связей с
> этой сущностью. Связь, тоже вводится на инфологическом уровне.
Ты как-то лихо из верного утверждения о наличии связи на инфологическом
уровне выводишь введение туда же и ключей. Основываясь на совершенно
неверной посылке "Если нет ключа, то не может быть и никаких связей с
этой сущностью". А она неверна даже дважды - и потому, что ключи отнюдь
не единственный механизм. И потому (и это главное), что на инфологическом
уровне _механизмы_ связей не нужны.
А как твое утверждение согласуется с твоим же, параллельным :
"Внешнего ключа нет в инфологической модели. Он появляется только
на уровне физической модели данных."
Это надо понимать так, что первычные есть, нет только внешних? Hо тогда
как связывать? Или это смена точки зрения на верную, но пока лишь на
уровне внешних? :)
> Именно, одна маленькая базка. У сущности "Платежное Поручение" просто куча
> атрибутов, ссылающихся на сущности БД внешних систем. Hомер счета, например,
> ИHH плательщика и т.д.
Это не сущность БД внешних систем. Это просто атрибут, _данной_ БД.
> При этом сущности типа "Счет" не хранятся в этой маленькой локальной базке.
> Каким боком тут помогут СК - неясно. Изменилась разрядность счета или ИHH -
> все перелопачивается в обоих случаях.
Общая проблема вводимых данных. От нее избавиться нельзя, но можно сделать
это на самом ответственном атрибуте - ключе. Поэтому _все_ перелопачивается
лишь при неиспользовании суррогатов. Подробнее - в ответе на другое письмо.
> Изменения прикладной логики и уровня представлений придется проводить в
> любом случае. А изменения уровня БД - это малая часть затрат по сравнения с
> логикой приложения и представления, поэтому ими можно пренебречь ради того,
> чтобы эту прикладную логику упростить.
Это даже более, чем неверно. Подробнее... ну, ты уже в курсе :) - параллельно.
--
Владимир Павликов.
Отправлено через сервер Talk.Ru - http://www.talk.ru
--- ifmail v.2.15dev5
* Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
