xenixВопрос такой: стоит ли запихать и "нас" и клиентов в одну таблицу "контрагенты"/"клиенты" или лучше разнести по разным?
Рассмотрите картину: данные лежат в одной таблице, над ней сделаны две вьюхи "мы" и "они". После этого придумайте хоть один аргумент держать в разных и оцените его серьёзность.

vmagТолько из-за этого я бы разнёс по разным, ибо слева "Мы" вырисовывается мини кадрово-зарплатная задача, которую можно будет расширять бесконечно, а справа "Клиенты" у которых максимум что будет, так это название, инн,
А потом в рамках а-ля CRM у этих клиентов пойдут сотрудники с телефонами, причём привязанные к разным департаментам и филиалам....

skyANAВ системе "Мастер-Тур", что занимает большую часть рынка программного обеспечения для туризма в России, одна таблица Partners и по ней построены представления вида Hotels, Touroperators и т.п.
На глаз это вполне разумное решение.

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

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

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

ViPRosЕсли б проектировщик не пытался отождествлять объект и его роли,
Именно. Очень точная формулировка. Объекты - в списке объектов, роли - отдельно. Тогда всё легко застёгивается любым потребным образом.

Станислав КлевцовВсе в одну таблицу , только добавить признак (клиент - 2 \контрагенты - 1),
А потом появится тот, кто является и клиентом, и контрагентом. Признак - плохое решение.