Для меня это непонятно зачем рубить сук на котором сидите) удалять интересные вопросы пользователей которые относятся к ИТ и не нарушают никакие правила пользования сервиса
Проблема в том, что закрывая глаза на такой шлак, с ресурса можно отпугнуть профессионалов, которые хотят решать интересные задачи, а не точить лясы и упражняться в психологии в очередном "как себя мотивировать писать кода". Если давать слабину, то ресурс быстро превратится в форум, а на форумах у посетителей принципиально другие цели и вообще контингент там другой.
> у области должен быть только один owner и не при каких обстоятельствах не должно быть более одного
Это сейчас так, а потом правила могут измениться :)
Либо сделайте роль в таблице сопряжения и проверяйте уникальность владельца на уровне приложения (гибко, но менее надёжно).
Либо сделайте в таблице областей owner_id и отдельную таблицу сопряжения без ролей (надёжнее и всегда можно сконвертироваться в первый вариант с ролями).
В таком случае, либо оставьте всё, как есть, либо сделайте так, как я предложил в комментариях к своему ответу. Промежуточные варианты - это мутный компромисс, от которого толку не будет.
В CRM очень часто требуется гибкость, особенно в плане ролей. И вы, занимаясь преждевременной оптимизацией, пилите ногу, на которой стоите (вот так изящно я соединил две пословицы, да). Сделайте расширяемую архитектуру, а оптимизацией занимайтесь только тогда, когда в ней реально возникнет необходимость и в минимально возможном объёме. Потому что дописывать эту CRM вам ещё много лет и вставляя такие костыли в самое ядро системы вы копаете себе яму.
"Дополнительный" код достаточно грамотно организовать, нагрузки на БД не будет. Зато вы получите возможность закреплять за одним пользователем несколько областей (суперадмин какой-нибудь), за одной областью несколько пользователей и ввести систему ролей. В перспективе это значительно важнее, чем пара методов для создания пользователей.
Ну так это и есть денормализация. Но, судя по тому, что пишет Александр Аблизин, у него денормализация не ради увеличения производительности, а из-за кривой схемы данных.
В таком случае, я бы на вашем месте из Пользователя упоминание Области убрал полностью, а в Области создал поле owner_id или manager_id, в зависимости от контекста (user_id слишком общее название). И отдельно добавил бы таблицу сопряжения Пользователей и Областей. Можно в Области вообще не указывать владельца, если в таблице сопряжений добавить поле role.
У него же проблема не в связях, а в денормализации из-за которой приходится делать три запроса при создании сущностей. Какой синтаксис создания используется неважно - проблему это не решает.
У них есть телефонная поддержка, я звонил туда несколько раз, но это было давно, соответственно, я не помню а) где найти номер и б) говорят ли они по-русски. Уверен, если вы начнёте с microsoft.com, через пару минут вы найдёте нужный канал связи.
В таком случае могу сказать только, что у вас где-то ошибка. Более подробно долго будет писать - там достаточно много разных вариантов. Тем более, что у других всё работает.
