iBase.ru Forum

Добрый. Подскажите, плиз...
Предлагается хранить мета часть БД описывающую структуру этой БД.
и формировать эту структуру на лету...
правильно ли это?
Заранее спасибо

"хранить", "формировать", "на лету"...

?

Типа, как в 1С - перестройка метаданных на ходу (с сохранением данных) согласно конфигурации?
Нет, это фантастика

Может, MSSQL такое с собой делать и позволяет, хотя и его база частенько от "работы" 1С разваливается, а в FB... Наверное, реализовать возможно, но мне страшно представить, со сколькими трудностями и граблями придётся столкнуться.

Занимаюсь документооборотом
Стадия проектирования системы
Имею след таблицы:
__ __ и таблицу ассоциаций __
TabDoc FieldDoc Assoc
-- -- --
pkDoc pkField pk
Name Name fkDoc
__ __ fkField
--

На основе данных, хранящихся в таблицах TabDoc и FieldDoc предлагаю генерить физические таблицы.
На сколко это правильно?

Имею след таблицы:
__
TabDoc
--
pkDoc
Name
--
__
FieldDoc
--
pkField
Name
--
__

таблицу ассоциаций
__
Assoc
--
pk
fkFeild
fkDoc
--
__

предлагаю генерить физические таблицы.

не пойдет.

Тогда подскажите как живут квазиструктурированные данные, причем типы этих данных не определены?
см:

http://www.osp.ru/text/print/302/181940.html
Рис. 2.


Там описана схема в которой не определено количество типов.
Это количество и сами типы я предполагаю определять в мета табличках...
Тогда при этом надо формировать физические таблички на лету

ну и делай так. можешь еще почитать ООП в РСУБД, статью Котляревского на сайте.

как живут квазиструктурированные данные, причем типы этих данных не определены?

системы такие есть, их мало, но они есть. И как правило они оперируют не очень большим объемом данных. В отношении документооборота пытаться сделать динамическое хранение любых атрибутов любых документов, да еще не зная типов данных - утопия.
Если ты не знаешь типов данных, что ты с ними будешь делать? Т.е. зачем ты их хранишь как атрибуты?
Кроме этого у тебя и приложение должно быть как "универсальный конструктор". На 1С 8 тебе уже намекнули, если хочешь окунуться в этот омут - дерзай. Я бы посоветовал подумать сначала.

Не у меня все проше, я с типами определился. Тут вопросов нет
Я не определился со структурой докуменов.
На приведенном рисунке вместо tbl_var_char c типами я предлагаю хранить документы, состав которых описан во второй мета табличке...

К сожалению не сталкивался я в свое практике с 1С...
а может это и хорошо:)

STWF на тему "структура имени Тенцера". Тормоза жуткие, но тем не менее - в точности как ты описываешь: хранение произвольного числа произвольных атрибутов произвольных документов.

Я не определился со структурой докуменов.

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

состав которых описан во второй мета табличке...

предлагаешь себе? предлагай. я это все проходил в 1991 году, мне больше не надо.

Верю, поэтому и обратился за помощью

в моем понимании документ - состоит из разделов (их количество не определено) и каждый раздел состоит из полей (их количество тоже не определно).

К сожалению определиться с полным перечнем разделов и полей я не могу по объективным причинам (сами предметники не знаю точно что за поля должны быть, а базу под них делать надо...)

Соответственно документов может быть сколь угодно много и езе больше экземпляров раздела...

Поэтому и пришел к мысле что для каждоко раздела формировать таблицу с определенными полями

Вот в кратце как родилась такая идея у меня.

с полным перечнем разделов и полей я не могу по объективным причинам (сами предметники не знаю точно что за поля должны быть

то есть, на данный момент ни одного реального документа, подлежащего хранению, нет?
я еще раз спрашиваю, что ты собираешься делать с неизвестными атрибутами неизветного типа - искать по ним, суммировать, и т.п.?
Может, они тебе вообще не нужны, тогда просто храни документ в blob.

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

И еще если хранить документы в BLOB-е то тогданадо будет знать как этот документ разбирать для просмотра... Так?

Я пока не понял как в качестве значения атрибутов хранит значения, взятые их справочников те надо хранить само значение или класскод этого значения...

что-что?

тогданадо будет знать как этот документ разбирать для просмотра

что значит "разбирать"? Если ты имеешь в виду типы документов, то есть логические типы - приказ, счет, накладная, объяснительная... -, и есть физические типы - doc, xls, txt и так далее.
если закидываешь док в блоб, ну так и укажи что это док. а при чтении из блоба сохрани его и вызови word.
Еще я бы посоветовал хранить реальные имена документов, как они были залиты в систему.

в общем, велосипед все это. кроме того, на рынке есть много аналогичных систем, от простых до сложных.

Да я знаю, что систем много, но задача стоит именно разработать

Сбасибо что подсказали, по крайней мере я получил направление в котором двигаться

Благодарю всех, кто принял участие в моем обучении