Да, рабочий вариант.

Спасибо :)

Только эту ссылку я бы не вшил в таблицу контрагента, а сделал отдельной таблицей связей. Можно с полем типа её сделать, чтобы была 1 таблица связей а не 3.

вшивать её не в контрагента, а в ип / ооо т. д.

Один контрагент не может быть одновременно и ип и ооо :)

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

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

Нет, вшивать не стоит. Рано или поздно придётся учитывать логику, когда данные по контрагенту есть, а по физику нет. И что тогда ты сделаешь? )

Нет, такого быть не должно

Хахаха ) Вот тут и прикол главный

При создании контрагента - обязательно создаётся или ИП или ООО или что-то ещё. Это требование системы

Такое может быть только в случае нарушения БД

Закон Мерфи: все, что может случиться, обязательно случится. Лучше быть к этому готовым 😋

Ну это нарушение целостности данных

Требования к системе меняются со временем

Тогда и код менять, если требования поменяются :)
Но это требование такое, что мы предполагаем, что вероятность его изменения крайне мала

Ладно, другой вопрос: сколько времени ты будешь поддерживать ту систему, которую сейчас разрабатываешь (с контрагентами и пр.)?

дооолго :)
по крайней мере так планирую)))

Тогда делай любым понравившимся тебе способом, и через 1-3 года в любом случае увидишь, к чему тебя это привело. Сделаешь выводы, какими бы они ни были.

Очень универсальный ответ :)

Есть два подхода.

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

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