softwarerКот МатроскинТочнее, единый взаимоисключающий признак (как у предыдущего оратора) - плохое решение. Гибче всего, конечно, делать список множеств ("клиенты", "контрагенты", "банки", "нерезиденты", "физ.лица", ..) и включать организацию в них независимо.
На практике встречаются очень запутанные ситуации: скажем, есть компания. Одному её департаменту мы что-то продаём, другой что-то продаёт нам, с третьим заключаем договор на сервисное обслуживание. Другой компании мы только продаём, в три разных департамента, оформленных как два юридических лица. Итп.

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

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

ViPRosprog123,

нет, кода мало
должен быть контекст, контекстные роли,..., интерпретатор контекста

ну пусть это будет код контекста, так устроит?:)

Кот Матроскинprog123 В какой ипостаси выступал контрагент - решается кодом операции в соответствующей таблице.

Это все замечательно, но чтобы контрагент занял место в оной соответствующей таблице - например, их список надо показать пользователю, чтобы пользователь мог выбрать. И пользователь, собака такая, решительно недоволен тем, что в списке для выбора банка-корреспондента он видит [в том числе] сотрудников (которые тоже хранятся в таблице контрагентов)
Т.е. нужно как-то хранить, в каких ипостасях контрагент может выступать в той самой "соответствующей таблице с кодом операции"

Читайте древние священные буквари, где выбито в камне - "интерфейс должен быть отделен от декларирования данных":)

ViPRosprog123,

ты понимаешь, контекст как то должен быть интерпретирован, и не человеком , а машиной
чек конечно ЗНАЕТ что тут код если = продавец, то кто то является продавцом
а машина не знает , чистое совпадение кода и понятия редко бывает
потому должны быть правила задания контекста, идентификации контекста, интерпретации контекста в каком то контексте :)

Пусть человеки вместе с машиной найдут по коду - всё остальное!

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


Читайте древние священные буквари, где выбито в камне - "интерфейс должен быть отделен от декларирования данных":)

При чем тут отделение интерфейса? Отделяя или не отделяя интерфейс, Вам придется хранить возможные роли контрагента.

Прочитайте сначала букварь. Можете спросить у нашего строгого Господина, он наверное подскажет.

ViPRosprog123пропущено...


Пусть человеки вместе с машиной найдут по коду - всё остальное!
человеческие знания в башке человека
он как то свои знания маппить на тот мусор в виде кода, который он ж намусорил
обычно потом оболганная ЧАСТЬ этих знаний кочует в бумагу на языке отличном от языка кодирования
когда другой чек пытается со своей колокольни интерпретированную (дважды оболганную) Часть маппить на тот мусор начинается Кошмар, постепенно ценность мусора приближается к нулю

В правильной базе метаданных кот наплакал.