Одна щирокая таблица. Я стараюсь не делать наследования на таблицах, держу более-менее однообразные данные в широких. Так проще (практичнее) но менее реляционно-правильно и архитектурно изыскано.

Лучше не ты, давно уже переписываемся через форум.

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

Разделение физиков и юриков по разным таблицам я описываю применительно к крупному корпоративному проекту, где такое решение я считаю наиболее подходящим:
Физики и юрики играют разные роли в разных кейсах.
На картотеку организаций опираются очень важные сущности - договора, сделки и т.п. Запросы по ним уже получаются достаточно тяжелыми, лишние записи о физиках в тех же таблицах уменьшили быстродействие, количество физиков в крупной организации исчисляется многими тысячами.
У физиков хватает своих замомрочек - должности, назначения и пр., количество кадровых записей о физиках таково, что лишние записи в таблице тоже понапрасну просаживали бы ресурсы сервера.

Итак, для корпоративного учета я считаю лучше разделять физиков и юриков по разным таблицам.

Что еще надо учитывать при построении картотеки контрагентов.

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

Далее сказанное, наверное, по большей части будет относится к учетным системам финансового толка (что знаю - о том пою, о чем не знаю - не пою).

Обязательно хранение и ИСПОЛЬЗОВАНИЕ информации о взаимоотношениях компаний парент-чаилд. Сделки заключаются с конкретным юрлицом, а вот риски висят на всем конгломерате компаний, образующих холдниг. Поэтому при учете лимитов как правило все сделки, относящиеся к одному холдингу суммируются. Гикнется голова - все дочки полетят следом.

Очень сильно можно сыграть на парент-чаилд относительно себя, любимых. Подавляющее большинство финансовых программ позволяет определить одну компанию как МЫ, НАША компания, все остальные становятся второй, другой строной в сдедках/договорах. И тогда неизбежно возникают проблемы при учете от лица нескольких организаций, имеющих одного владельца, входящих в один холдинг. Ведем учет от лица компании А. МЫ, А, разместили депозит компании Б. Но компания Б - тоже другие МЫ, для нее надо учитывать симметичный заем на эту же сумму. Любая сделка между двумя своими компаниями должна учитываться дважды, зеркально. Я видел разной степени кривости попытки такого решения в рахных системах. Обычно заводится одна сделка от лица компнании А, а вторая сделка генерится зеркально по нажатию специальной кнопки. Но потом они никак больше не синхронизируются и не отслеживаются. В худшем случае поднимется несколько инстансов программы, по одному для кждой комнании холдинга и потом начинается жутчайший кошмар разъезжания и синхронизации общих данных. Накручиваются суперпупер джобы и адаптеры...

А всей этой херни можно было с самого начала избежать, если изначально заложить правильную модель в картотеку контрагентов. Если определить МЫ как холдинг, содержащий разные юридически полноценные компании, или заложить в систему возможность наличия (и соответвующей обработки признака МЫ более чем у одной компании). Тогда любую сделку можно регистрировать один раз, с указанием Сторона1 (А, МЫ) и Сторона2 (Б, тоже МЫ). Заплатить за это придется программным удвоением сделок при вставании на точку зрению любой компании.

Продолжение следует

Структура компаний, филиалы и т.п.

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

ОБЯЗАТЕЛЬНО!!! Графическая визуализация отношений парент-чаилд в виде дерева. Сколькоя видел систем, где окошечко парент на карточке организации было, но представлять всю эту структуру надо было исключительно в голове!

Второе сразу тесно пересекается с должностным расписанием. Если необходимо хранить и обрабатывать информацию о документах, договорах - без этого не обойтись. Причем хранить и использовать придется данные включая даже падежи, иначе не составить строку "Господину Иванову И. И. Главному помошнику Старшего начальника Бестолкового департамента Ухрюпинского филала ООО Рога и копыта".

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

Надо/полезно хранить информацию о подчиненности должностей или конкретных сотрудников друг другу. Надо иметь возможность вытаскивать руководителей подразделений. Часто - главных бухгалтеров или руководителей по определенным направлениям бизнеса.

Географическая привязка.

Можно использовать полноценный кладр, можно по-проще - стринговые тупые адреса и отдельную привязку к городам/странам.

Всяческие коды.

Можно сделать справочник типов кодов и по-еавешному заталкивать туда ИНН, КПП, ОГРН, ОКВЭД... Можно наращивать столбцы таблицы контрагентов при появлении новых типов кодов. У каждого свои плюсы и минусы, если только показывать на экране в виде удобной для прораммиста форме, то первый способ лучше. Если интенсивно использовтать кодовые атрибуты в формах, отчетах, документах, то я выбираю второй.

Бозовая картотека контрагентов должна обходиться в пару дюжин таблиц.

JaDiДля двух разных компаний одно и то же событие или объект может нести СОВЕРШЕННО разное назначение, вестись совершенно другим способом и более того, представлено совершенно другими документами! Даже элементарные операции по оплате договора -- это совсем разные документы для двух сторон. Или простая нумерация входящей корреспонденции с договорами и счетами. Я уж не говорю про персонал, работающий независимо друг от друга.
Я имел в виду управлеческий финансовый учет сделлк-договоров. Причем он физически ведется в одном месте. Договор (сделка) между двумя сторонами - это один документ. Условия в нем совершенно тождественно-симметричны для двух сторон. Одна и та же дата, один и тот же срок, ставка. Только одна сторона дает взаймы (размещает), актив а другая - берет взаймы, пассив. В этом смысле последствия для учета должны быть симметричными.