Вопрос по теории

← →
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]
>Ну, тут же очевидно, что важно все это одновременно ! :))

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

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

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

Пример.

Таблица 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. Причем СУБД не даст удалить запись из документов, если на нее ссылается счет.

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

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

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

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

ОК!

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

Спасибо

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

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

А также Johnmen и HSolo!

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

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

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

Можно и так:

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

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

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