Схема отношений между сущностями - посоветуйте как правильно

[Артем Enot Грунин]

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

[senin24]

а как быть с тем, что в реальности в моем случае, у возможной сделки один клиент и много подрядчиков? насколько я понял, в системе по умолчанию к возможной сделке можно прикрепить только одну организацию, т.е. есть отношение 1:N (Орг - Возм.сделка)
Если я добавлю между Возможной сделкой и Организацией отношение N:N это не нарушит какую-нибудь другую логику взаимоотношений между сущностями?
Обновил схему.

[-O_o-]

Цитата:

Сообщение от senin24

а как быть с тем, что в реальности в моем случае, у возможной сделки один клиент и много подрядчиков? насколько я понял, в системе по умолчанию к возможной сделке можно прикрепить только одну организацию, т.е. есть отношение 1:N (Орг - Возм.сделка)
Если я добавлю между Возможной сделкой и Организацией отношение N:N это не нарушит какую-нибудь другую логику взаимоотношений между сущностями?
Обновил схему.

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

1. Насчет сущности "Проект"
Почему вы решили использовать ВС для решения вашего вопроса? Что будите делать, когда компания начнет заниматься продажами со (счетами, заказами, договорами и ком.предами) ?

2. Насчет ролей, которые будут принимать организации в проекте

Цитата:

Если вы уверены, что этого достаточно - действуйте. Если же ролей хотя бы три (партнер, субподрядчик, генподрядчик, офшор, служба доставки крошки-картошки). Я бы пересмотрел мнение на предмет соединений.

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

3. Справочник услуг.
Рекомендовал бы связаться его с сущностью "участник" отношением N:N. Таким образом у вас будет контейнер по проекту. Какие компании с какой ролью и услугой.

3. По поводу диаграммы.
В стандартной модели CRM у одной организации куча контактов, а не наоборот. И лучше уберите стрелочки, а то запутанно все

Вроде бы ничего не забыл

[senin24]

Спасибо за развернутый ответ.
Стрелочки точно вносят смуту - уберу))

1. По ВС - думаю не проблема - потом можно будет добавить поле с выбором вида ВС (Проект, Заказ, Продажа и т.п.). А делать отдельную сущность, которая по сути бы повторяла функционал ВС - слишком трудоемко.

2 и 3. Специфики такова, что Подрядчики занимаются строго определенными услугами и каждый раз указывать для них заново роль (тип услуги) – неудобно и чревато ошибками. Но идея очень интересная.

4. Да, вы правы, я ошибся, конечно же стандартно одна Организация ко множеству контактов

Обновил схему