17-77Кот Матроскин,
связь самая прямая:
Mr.FontaineОператор создаёт заявку, в которой указывает требуется ли для данной заявки договор и заказ
это означает, что надо показать форму заявки с полями ввода - это лишнее время => лишнее время в очереди => меньше клиентов => меньше денег => банкротство

"Оператор указывает в заявке, требуется ли договор и заказ" - это уже как раз не схема данных, а описание интерфейса - и оно может быть кривым.
А в базе сущности "заявка", "договор", "заказ", "платеж", "черт лысый" и т.п. - могут создаваться одним кликом мышки, по описанным заранее шаблонам.
Может возникнуть вопрос "Для чего они тогда нужны?" - а для того, чтобы при изменении бизнес-процесса не надо было менять схему данных, и все отчеты, аналитика и т.п. остались актуальными.

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

Mr.FontaineКот Матроскин Что касается самой схемы - мне флаги "требуется договор", "требуется заказ" в заявке тоже кажутся излишними. Довольно очевидно, что требуется ли такой-то заявке договор - это компетенция не девочки оператора, а бизнес-аналитика, которому надо дать механизм указания "Для обладающих такими-то свойствами заявок нужно автоматически создавать договор".
Ну вот по теме пошла критика. Объясню. Во-первых, у ТС в первом сообщении была фраза авторНа некоторые услуги оформляются заказы. Параллельно заказу может быть оформлен договор. Соответственно данные для договора берутся из заказа. Некоторые услуги оказываются только по договорам.
Поэтому в таблице "Услуги" есть флаг "Требуется договор". Если этот флаг отмечен, то договор должен будет создаваться автоматически. Но как быть с услугой у которой нет такого флага? Тут конечно надо послушать автора топика по этому вопросу
Я конечно фонтанировать своими фантазими засирая топик, например, поставить такой же флаг "Требуется договор" у конкретного клиента или клиентов разбить на группы и к группе привязать этот флаг, но опять же это больше к интерфейсу вопросы.

Ну я бы не сказал что это вопросы к интерфейсу - но соглашусь с тем, что вопросы шаблонирования операций явно пока для ТС-а не очень актуальны, и с темой топика их лучше не путать


Mr.FontaineМне же флаги "требуется договор", "требуется заказ" в таблице заявки кажутся необходимыми, чтобы по их наличию/отсутствию искать информацию о договоре и заказе в соответствующих таблицах. Как они будут заполняться не столь важно. Главное их назначение - при наличии флага бежать в соответствующую таблицу с договорами и/или заказами для получения необходимой информации.
Это не очень хорошо, поскольку Вы дублируете информацию и, следовательно, напрашиваетесь на аномалии обновления - что будет, если договор удалили, а галочку не сняли? или наоборот, галочку не поставили, а договор создали?
Сделать соединение по номеру заявки с таблицей договоров или заказов - недорогая операция, почему бы не делать ее в любом случае? И даже если Вы считаете ее дорогой - все равно имеет смысл построить эти флаги в виде вычисляемых полей, возложив
проблему синхронизации на СУБД. Но в модели им делать нечего.

Mr.FontaineКот Матроскинпропущено...

Это не очень хорошо, поскольку Вы дублируете информацию и, следовательно, напрашиваетесь на аномалии обновления - что будет, если договор удалили, а галочку не сняли? или наоборот, галочку не поставили, а договор создали?
Сделать соединение по номеру заявки с таблицей договоров или заказов - недорогая операция, почему бы не делать ее в любом случае? И даже если Вы считаете ее дорогой - все равно имеет смысл построить эти флаги в виде вычисляемых полей, возложив
проблему синхронизации на СУБД. Но в модели им делать нечего.
Во-первых, информация не дублируется. Она указывает, какая информация требуется для выполнения заявки. Если в заявке стоит что договор необходим, а в таблице договоров у этого клиента по указанной в заявке услуге договора нет, то заявка не может быть выполнена, пока не будет создан договор.

При таком толковании у Вас нарушение 3НФ- в заявке атрибут "необходим договор" зависит от неключевого атрибута "ID услуги" (поскольку у услуги уже есть атрибут "необходим договор").