|
|
|
Реализация журнала проводок.
|
|||
|---|---|---|---|
|
#18+
Исправляюсь. 1. То что Вы хототе организовать - это объект документ и объекты порожденные от объекта документ. В такой БД как PostgreSQL наследование включено в функционал БД. Если БД не поддерживает такой функционал - и литература и визуальные средства предлагают реализовать наследование при помощи заведения в таблицу-родитель специального поля "дискриминант" Таблица-родитель ИД-документа -------------------- Дискриминант (int) Таблица-потомок А ИД-документа (ссылка на ИД-родителя) -------------------------------------------- поле1... Таблица-потомок Б ИД-документа (ссылка на ИД-родителя) -------------------------------------------- поле1... Насколько это соответсвует реляционной модели данных? Вобщем, исходя из требования извлекать информацию только из таблиц, наверное, нужно еще создать еще таблицу Дискриминанты Дискриминант (int) ----------------------------------- ИмяТаблицы (varchar) 2. Хранить в документе ссылку на проводку кажется хорошим ходом. Поскольку именно из документа Вы проводите и отменяете проведения документа. Выбор того или иного варианта реляционной модели зависит от того как Вы собираетесь использовать данные. Например получить ссылку на документ из таблицы проводок скорее важно для большей информативности. Посмотреть что и как бало проведено. Поэтому думать о производительности в данном случае не так важно. В то же время проводиться и отменяться документы будут в массовом порядке. Поэтому хранить в документе ИД проводки - я за. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2007, 00:05 |
|
||
|
Реализация журнала проводок.
|
|||
|---|---|---|---|
|
#18+
SPQR БизонКак с точки зрения реляционной модели реализовать, ссылку на несколько таблиц из одного поля. Никак. Все д.б. наоборот - эти "несколько таблиц" должны ссылать на одно поле в таблице документов. Ссылка в смысле Foreign key? Так просто создаёшь несколько ограничений FK для одного поля таблицы на PK в разных других таблицах. Только толку от таких FK обычно не много. Формально можно смоделировать сущность документ, и дочерние к этой сущности специализированные сущности для конкретных видов документов. Связать их по PK. Из сущности проводка смоделировать связь с сущностью документ. Однако в физической модели реляционной БД нет нужды создавать таблицу для сущности документ, поскольку она будет состоять только из PK, соответсвенно моделировать связи других сущностей с документом с помощью FK тоже не приходится. В объектных БД гораздо проще смоделировать абстрактный тип документ и специализированные подтипы конкретных видов документов. Короче, правильная логическая модель не всегда имеет взаимнооднозначную физическую реализацию. ИМХО, нет нужды извращаться только для того чтобы впихнуть невпихуемое по крайней мере СУБД развиваются и для того, чтобы лучше отражать конструкции логического моделирования. Сейчас мы имеем такие СУБД, какие имеем со всеми ограничениями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2007, 02:20 |
|
||
|
|

start [/forum/topic.php?fid=32&startmsg=34989780&tid=1544148]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
182ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
| others: | 247ms |
| total: | 537ms |

| 0 / 0 |
