Здравствуйте, Ocenochka, Вы писали:

O>Здравствуйте, akasoft, Вы писали:

O>>> Если да, то я вижу несколько проблем:
A>>Пока я вижу такую проблему, что ты ТЗ знаешь, но мне его не говоришь. Поэтому в ответах мне придётся прибегать к боевой телепатии.
O> Это неизбежно в беседах такого рода — все ТЗ я сообщить не могу по понятным причинам. Могу лишь абстрактно обрисовать проблему — есть две сущности предметной области, но они на столько похожи данными и логикой, что вроде бы являются единым.

O>>> 1. Для получения всех "утвержденных документов" нужно проверять что документ не был исключен после включения, при этом запрос к БД усложняется до хранимой процедуры либо если хотим логику в коде, то придется доставать всю таблицу и на клиенте с ней работать.
A>>По мне это всего-лишь поле типа один бит, т.е.
A>>

A>>SELECT * FROM document WHERE approved = true
A>>

O> Тут моя вина. Забыл указать, что ТЗ подразумевает хранение истории по утверждению/отклонению документов. Один и тот же документ может утверждаться, потом отклоняться, потом опять утверждаться но уже с некоторыми измененными полями и так много раз. Сейчас это сделано одной записью в таблице на каждое изменение. Простой проверкой статуса не обойтись. Может быть историю нужно было делать по другому, но других красивых вариантов я не нашел.

O>>> 2. Если в "утвержденном документе" есть ссылки и свойства, которых нет в "проекте документа", то сущности уже не так похожи. А если 30% свойств будет отличаться? А если 50%? Тут вроде как здравый смысл рулит, но он у каждого свой. Вот интересно кто что по этому поводу думает.
A>>Здравый смысл говорит, что сначала появляется проект, потом он обрастает свойствами, потом его обсуждают и в конце концов утверждают, а когда утвердили, то уже добавлять/убирать нельзя, только исполнять.


Мне кажется если сделать структуру таблиц более нормализованной то будет проще организовать все в одной схеме. Как уже сказали — ввести состояния.
Взять таблицу Documents, описывающую шапку документа. К ней прикрутить таблицу Versions — с состояниями — в ней же и хранится вся история состояний с документом. Свойства документа — тоже отдельная таблица — properties и таблица связей propToVersion в которой будет связь версии со свойством.
Это примерно в общем виде, наверное косячки есть, можно продумать подробнее. Правда я не знаю как такая структура ложится на ORM