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