|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Serg Vasiltsoff 2:5020/400 19 Feb 2001 22:40:40
To : All
Subject : Re: идеология схемы бд
--------------------------------------------------------------------------------
> > > Hо отдельная проблема заключается и в том, что сущность "человек"
также
> > > может меняться по времени:
> > > событие "человек сменил фамилию".
> >
> > Достаточно типичная ситуация.
> > Вопрос ?1 - а оно надо?!
> >
> > Вопрос ?2 - а пробовали схему "Параметры = приказы на изменение
> параметров."
> > с пересчетом состояния на требуемую дату.
>
> Извини, не понял.
У нас есть два варианта. первый - протоколирование, это когда действие
порождает запись в протоколе. Второе - приказы. Это когда приказ порождает
изменение текущего состояния. В обоих случаях можно реконструировать
состояние на дату, но в случае с историей реконструкция вторична, в случае с
приказами - первична. Грань тут тонкая, но она есть.
Крайний вариант существования такой системы - только приказы, тогда система
существует без понятия "текущая дата". Каждый приказ существует от своей
даты до даты следующего приказа.
Я не буду говорить об организации хренения данных в таких системах - уйдем
далеко в сторону.
Завершая обсуждения ПК замечу, что ПК определяет сущность. Кроме ПК у
сущности может быть сколько угодно уникальностей, но ПК останется ПК.
Составной ПК - это уже характеристика сущности, а ПК не может быть
характеристикой. Он - другая сторона сущности. Так, напрример, объединение
ФК в уникальные индексы при построении таблиц связи порождает условную
ассоциацию... Hу да ладно, дальше уже темный лес абстрактного дизайна БД.
--- ifmail v.2.15dev5
* Origin: Lime Systems (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
