Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2004.05.23;
Скачать: CL | DM;

Вниз

Вопрос по теории   Найти похожие ветки 

 
kalliopiy   (2004-04-27 14:20) [0]

Здравствуйте!

Как на ваш взгляд лучше поступить в следующей ситуации. Есть некоторая последовательность формализованных документов, которая принимается для обработки и хранения в базе данных. Последовательность эта характеризуется тем, что фактически за одним документом следует другой, за вторым третий и т.д. (в общей сложности где-то 10 документов разлиного вида), но самое главное, что всегда эта цепочка идет без каких-либо разветвлений (на один документ - один следующий документ). Т.е. фактически всегда получается отношение "один к одному". И в связи с этим у меня возник вопрос - как все это лучше реализовать в БД? Делать в одной таблице с кучей полей (даже боюсь предположить сколько их там может быть) или разносить все по разным таблицам (каждый документ - отдельная таблица), связанных этим самым отношением "один к одному"?


 
Johnmen ©   (2004-04-27 14:22) [1]

>в общей сложности где-то 10 документов
>в одной таблице с кучей полей

куча ~ 10 полей ? :)


 
Карелин Артем ©   (2004-04-27 14:25) [2]

Если я правильно понял, хранить надо следующее:
1) один файл в blob-поле
2) идентификатор записи
3) идентификатор родительской записи (опционально. если ее нет, хранить null или отрицательное значение)
На структуру одной таблицы похоже?


 
kalliopiy   (2004-04-27 14:25) [3]


> Johnmen ©   (27.04.04 14:22) [1]

:))

Нет, документов приблизительно 10, а не полей. Ведь каждый документ формализован, как я сказал. И каждый характеризуется в среднем 10-15 полями, а не так, что на каждый документ свое поле.


 
Курдль ©   (2004-04-27 14:26) [4]


> Делать в одной таблице с кучей полей


> или разносить все по разным таблицам

Ни то, ни другое!
Если все поля в документах совпадают - писать в одной таблице по записи на документ. Если не совпадают - организовать базовую таблицу "документ" - а от нее по первичному ключу (inheritance-связь) все остальные. Связь между документами следует организовывать сообразно правилу формирования пакета, или как оно у Вас называется. Например - создать сущность "пакет", с которой по принципу многие-к-одному будут связаны разнородные документы одного пакета. (Если документы не имеют право повторяться - поставить уникальный индекс на поле типа DOC_TYPE).


 
Johnmen ©   (2004-04-27 14:31) [5]

>kalliopiy   (27.04.04 14:25) [3]

Т.е. ~ 150 полей ? Ну и что ?

А вообще, надо заранее определиться, что важнее, производительность, структурированность, ясность/понятность etc...


 
HSolo ©   (2004-04-27 14:32) [6]

10 полей - не куча :) Но если завтра документов в цепочке станет 11?
Может, лучше так:
1) Таблица - журнал документов: Id документа + атрибуты, к-рые есть во всех документах (№, дата, что там еще)
2..n) Таблицы атрибутов документов разного вида:
- Id документа из журнала документов
- атрибуты
n+1) Таблица для цепочек:
- Id предыдущего документа (из журнала)
- Id следующего документа (из журнала)


 
Курдль ©   (2004-04-27 14:35) [7]


> Т.е. ~ 150 полей ? Ну и что ?

Как это "что"? Не важно, 150 их, 15, или 1500! Но на горизонте тогда маячит нарушение целостности данных! Ведь если очистить все поля, принадлежащие, напр. 4-му документу, получится какая-то хрень (с), типа 3-й связан с 5-м через пень-колоду! И СУБД при этом ни на что не ругнется (ну, очистили - значит так надо!)


 
Johnmen ©   (2004-04-27 14:41) [8]

>Но на горизонте тогда маячит нарушение целостности данных!

Нарушение маячит, когда пытаются нарушить.
Я же чётко сказал, что надо определиться с тем, что важнее для функционирования...


 
kalliopiy   (2004-04-27 14:42) [9]


> Johnmen ©   (27.04.04 14:31) [5]

Ну, тут же очевидно, что важно все это одновременно ! :)) Мне же вот и хочется понять как так сделать, чтобы во всех этих пареметрах достигалась какая-то середина.
Так значит 150 полей в таблице - это не проблема?


> HSolo ©   (27.04.04 14:32) [6]

и

> Курдль ©   (27.04.04 14:26) [4]


Мне не очень понятны эти надстройки с журналами или пакетами. Не будет ли в этом некоторая избыточность? Хотя идея вроде бы достаточна интересная, но мне, наверное, не очень подходит.

Я могу попытаться объяснить немножко поподробнее. Есть такая цепочка документов (весьма разнородных, т.е. не одинаковых): заявка со своими параметрами, ответ на заявку, поручение (со своими параметрами), на поручение - счет, потом справка заказчика и т.д. Т.е. в процессе работы последовательно формируются различные документы, причем каждый следующий вытекает из предыдущего.


 
HSolo ©   (2004-04-27 14:48) [10]

> Мне не очень понятны эти надстройки с журналами или пакетами. Не будет ли в этом некоторая избыточность?

Считайте, что надстройка - это класс TDocument, а все остальные - это его потомки :) Ваша задача - связать различные документы друг с другом - как раз красиво (на мой взгляд :)) решается на уровне TDocument


 
Курдль ©   (2004-04-27 14:48) [11]


> Т.е. в процессе работы последовательно формируются различные
> документы, причем каждый следующий вытекает из предыдущего.

Это мы поняли и с первого раза. Но никто не заставляет Вас хранить их в виде каких-то загадочных цепочек. Создайте триггер на добавление документа (если рассматривать мой пример с таблицей "пакеты"), который не позволит добавить в пакет счет, пока в этом пакете нет поручения и заявки.


 
kalliopiy   (2004-04-27 14:51) [12]


> HSolo ©   (27.04.04 14:48) [10]

Но я между ними ничего общего кроме даты, номера и автора не нахожу. Так может не связываться ради этого с такой схемой. Мы же все таки не ООП занимаемся, а РЕЛЯЦИОННЫМИ базами данных.


 
Johnmen ©   (2004-04-27 14:57) [13]

>kalliopiy   (27.04.04 14:42) [9]
>Ну, тут же очевидно, что важно все это одновременно ! :))

Так в реальной жизни не бывает. Чтобы вес всех факторов был одинаков и максимально высок...:)

Я бы сделал для каждого вида документов отдельную таблицу. Пожалуй это наиболее компромиссный вариант между скоростью, сложностью и размером.


 
Курдль ©   (2004-04-27 14:58) [14]


> Мне не очень понятны эти надстройки с журналами или пакетами.

Пример.

Таблица 1:
DOCUMENTS:
DOC_ID, DOC_NAME, DOC_DATE, DOC_MAKER --создатель
primary key (DOC_ID)

Таблица 2:
INVOICES:
DOC_ID, INV_CODE, INV_SENDER, INV_RECIEVER
primary key (DOC_ID)
foreign key FK_DOC_ID(DOC_ID) references DOCUMENTS(DOC_ID)

Таким образом все базовые поля (те, что присутствуют в любом документе) будут храниться в родительской таблице DOCUMENTS, а счета - в наследованной INVOICES. Причем СУБД не даст удалить запись из документов, если на нее ссылается счет.


 
Курдль ©   (2004-04-27 15:01) [15]


> Так может не связываться ради этого с такой схемой. Мы же
> все таки не ООП занимаемся, а РЕЛЯЦИОННЫМИ базами данных.

Я Вам дал пример [14] самой махровой реляционщины!


 
HSolo ©   (2004-04-27 15:02) [16]

> kalliopiy   (27.04.04 14:51) [12]
Вам решать - Вы разработчик. Просто в моих проектах такая схема до сих пор себя оправдывала.


 
kalliopiy   (2004-04-27 15:14) [17]

ОК!

Всем громаднейшее спасибо. Я действительно всем благодарен.

Спасибо

> Курдль ©   (27.04.04 14:58) [14]

за усердие :))

А также Johnmen и HSolo!

Попытаюсь все еще раз хорошенько обдумать с учетом высказанных идей и выстроить схему БД нужным образом.


 
Курдль ©   (2004-04-27 15:17) [18]


> Спасибо
>
> > Курдль ©   (27.04.04 14:58) [14]
>
> за усердие :))

Не обольщайтесь! :)  Я просто привел выдержку из скрипта одной собственной базы (а уж с документами я ох... как много наработал) :)


 
asp ©   (2004-04-27 15:17) [19]

Можно и так:

Общая таблица документов:
DOC_TITLE (ID, DOC_NUM,..)
Последовательность:
DOC_CHAIN (PARENT_DOC, CHAIN_STEP, DOC_TITLE)
Где: PARENT_DOC - родительский документ последовательности
CHAIN_STEP - номер документа в последовательности
DOC_TITLE - ссылка на текущий документ в последовательности.

Если я правильно понял.



Страницы: 1 вся ветка

Текущий архив: 2004.05.23;
Скачать: CL | DM;

Наверх




Память: 0.52 MB
Время: 0.024 c
1-1083913249
pirate
2004-05-07 11:00
2004.05.23
TStrings глюк


8-1078388044
GH@ST
2004-03-04 11:14
2004.05.23
Как можно уменьшить JPG?


3-1083348601
Mister
2004-04-30 22:10
2004.05.23
MySQL+Delphi


7-1081866904
Beton-karton
2004-04-13 18:35
2004.05.23
Работа с Windows Mobile


3-1082701593
Andrey_Zh
2004-04-23 10:26
2004.05.23
Базы данных