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

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

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

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

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

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

К сожалению по моему ТЗ документ могут отклонить (перевести в проект) после утверждения, а потом опять утвердить его же, но слегка изменив.

A>Не может проект документа отличаться от самого себя, но наполнение его в моменты времени между началом проекта и утверждением может быть разным.

Логика работы с проектом отличается от лигики работы с утвержденным документом. Эти различия меня и смущают. Т.е. Вроде и один документ, но логика работы с ним довольно сильно расходится когда он утверджен и когда нет.

O>> 3. В одной таблице не получится поставить констрейнты на данные (не критично, но все же)
A>Это замечание моя боевая телепатия не осилила.

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

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

зы Спасибо за помощь, не смотря на необходимость в телепатии )