Всем привет.

Есть несколько таблиц, хранящих данные о документах согласно модели EAV. Хочется иметь для этих документов возможность контроля версий. Есть несколько идей (собственно все они всего лишь абберации одного подхода), но все они не кажутся мне оптимальными. Может кто нибудь поделиться опытом или своими догадками?

Для наглядности прикладываю схематичную картинку.

P.S. И еще один вопрос. Если допустить, что такая модель имеет право на существование, как надо построить SQL запрос, чтобы выбрать последнюю ревизию документа? Сложность в том, что в последней ревизии могло быть изменено значение только одного атрибута, значения остальных надо как-то подтянуть из предыдущих ревизий (причем, желательно, не выбирая вообще все значения для документа с определенным id_doc).

Всем заранее спасибо за участие

softwarer
Запрос действительно попроще получается. Немного переделал.

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

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

Необходима полная история изменений.

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

...и работать все должно на Postgres

ModelR,

Я исходил из следующих соображений: изначально хотел не разделять Documents и Documents_Revisions , вести все записи в одной таблице Documents . Но потом посчитал что во-первых, ревизии документов никогда не будут иметь таких свойств как blocked, blocked_by и blocked_from и соответственно для большей части таблицы эти свойства окажуться просто пустыми. Во-вторых, в 99% случаев работа идет с актуальной версией документа и наличие в таблице Documents мертвого груза при больших размерах может привести к замедлению работы. В общем я их разделил. И прямой связи между ними сейчас нет. В принципе ваши замечания 1 и 2 вытекают из этого решения. Скажите, насколько вообще целесообразны мои опасения, может сделать и историю и актуальные версии водной таблице?

Т.е. сейчас при модификации одного из свойств документа, должно происходить следующее
- строка, соответствующая старой ревизии документа, переносится из Documents в Documents_Revisions .
- в Documents записывается новая строка с новыми данными о версии документа (кто-когда-откуда изменил) и тем же id_doc.
- в Documents_Properties_XXX обновляется строка со старым значением свойства (active_to = <время новой ревизии> (наверно, действительно логичнее сделать FK)).
- в Documents_Properties_XXX записывается новая строка c новым значением свойства и ссылкой на новую ревизию документа.

Если слить Documents и Documents_Revisions процесс обновления получится гораздо проще конечно, но не станут ли в последствии тормозить выборки?

По третьему пункту. Да вы правы. Такого ограничения сейчас нет. Я правильно понимаю, что запрет на смену id_doctype для созданного документа должен решить проблему? Как это сделать пока не еще не разобрался. Вроде бы надо копать в сторону constraints, так?

Спасибо за советы )))

В этой теме в конце есть три ссылки. Должно помочь.

softwarer ,
Спасибо за критику )
Можно еще несколько вопросов?
softwarerНе думаю, что стоило разносить значения по такой куче таблиц. В результате даже простейшая операция "покажи мне документ целиком" превращается в сложный запрос, либо - что еще намного хуже - в запрос документа "по очереди по одному полю", операции поиска и прочее тоже усемеряются. Конечно, можно сделать view, но это в лучшем случае приблизит ситуацию к нормальной - если оптимизатор хорошо справится с работой.
Как по вашему, сколько типов достаточно? Если учесть что мы говорим не об абстрактных сущностях, а все таки о вполне конкретных -- документах? В принципе можно слить все числовые типы в один и выбросить логический тип... Или вы предлагаете более кардинальные меры?
softwarerСсылки на составные ключи - то еще удовольствие, не думаю, что есть смысл их особо лелеять.
Поясните пожалуйста в чем здесь проблема? Какая разница два поля в ключе или одно? Или это как то влияет на целостность данных?
softwarerУ меня есть ощущение, что у Вас здорово напутано со связями, но детально разбираться в том виде, в котором приведена диаграмма, нет никакого желания.
Они автоматов делались. Главное, что FK правильно стоит, значит и связи наверно в порядке.

ModelRУточните, что же в данной задачке?
Версии создаются автоматически каждый раз при внесении правок. Пользователь может изменять только актуальную версию документа.

И еще один вопрос.
Как сделать так, чтобы при выборке свойств документа запрос затрагивал только те таблицы в которых эти свойства реально присутствуют. Т.е. допустим, если документ имеет только три строковых свойства и одно текстовое, не делать join по таблицам для всех типов.

ModelRВ частности, если все на автомате, то как определяется id_docstate?
id_docstate определяет состояние документа, имеющее опосредованное отношение к версионности. Служит для организации базового документооборота. Если, допустим, есть документ, который должен пройти несколько инстанций перед окончательным утверждением. Определеяется пользователем. Это если кратко.