Ну таблица Контрагент тоже есть, я ее не привел чтобы упростить ответ.
А так - да, Контрагент ---> Клиент ---> Реквизиты

авторКак же ФИО может относиться и к физ лицам и к юр?
И видимо ФИО хранится в одном поле и используется либо как наименование организации, либо как фамилия имя отчество для физ/лица?
Ну что вы, как так можно? :) ФИО физлица для Юрика - это фио доверенного лица предприятия. А наименование организации лежит отдельно там где и положено - в реквизитах.

авторвидите, только из-за того что вы отвергаете мышление в терминах ООП вы сделали outer join, когда можно было join, что выполнится быстрее (незачем тащить реквизиты для физического лица). Это по мелочи.
При чем тут ООП? Я привел left join в качестве примера. Если мне нужны только физлица, то будет так:
Если юрики, то так:
Та же скорость выполнения, так что нет никаких мелочей

авторВ принципе таблица реквизиты у вас тоже самое что и у меня юр/лицо и здесь тоже наследование (таблица Реквизиты, в которой есть ссылка на Клиента и все прибамбасы: счет, банк и т.д).
Но явно не выделена сущность "Физическое лицо" и в этом ошибка проектирования.
А тут мне кажется совсем наоборот - у вас есть ошибочка, тут я согласен с www.fun4me.narod.ru :)

авторТеперь дальше...
Возникло новое требование.
Требуется создать справочник сотрудников, при чем сотрудник может быть клиентом.
Ваш действия?
Ну, этак если дальше пойдет, мы систему тут напишем. Задаром
Это уже на усмотрение организации системы. Для чего нужен справочник сотрудников? Как и кто с ними будет работать. Можно заводить сотрудников отдельно, отдельно их как клиентов и связывать с клиентом, можно еще как-то, можно поставить отметку на клиенте о том, что он является сотрудником. Тут никак ООП не может влиять. Хотя вы все-же приведите, как бы сделали вы.
============
www.fun4me.narod.ruЯ бы сказал, что контагент - это обобщение понятия физических и юридических лиц. То есть, сначала надо заводить физическое или юридическое лицо. Потом делать ссылку в контрагенте на это лицо.
Или наоборот - при создании клиента сначала создается контрагент, а от него наследуется клиент. Тогда проще будет - хотя бы ID будут одинаковые.

-- Tygra's --

softwarerРеальные структуры предъявляют еще большие требование - например, стоит помнить, что банки (в которых у контрагентов расчетные счета) имеют корр.счета в других банках, а сами банки при этом являются организациями и могут являться контрагентами. Впрочем, не понимаю, при чем здесь объектный подход - это вопрос грамотного или неграмотного проектирования в условиях той или иной конкретной задачи . ER-проектирование - достаточно "объектно".
Полностью поддерживаю.

авторВо всяком случае, наличие в 50 различных запросах фразы "[Юридическое лицо] JOIN [контрагент]" меня серьезно насторожит.
Ну у меня физики и без вьюх - это одна таблица. А так - да, вьюхи нужны. Тока в MS SQL они странно работают, планы у них часто слетают. Может просто не знаю, как лечить, но пока что вьюхами особо не увлекаюсь.

Роман ДынникЭто как? т.е. в контрагенте у вас будет 2-а поля одно из которых ссылается на ф/л, другое на ю/л? Это не правильно.
Нет, это будет скорее всего, как я выше написал.

авторЭто уже бизнеслогика.
Правильно, это все бизнес-логика и архитектура БД. И никакого ООП.

ShtockГоспода, только довайте не будем спорить по поводу контрагентов,физиков и юриков.Если есть желание подискутировать по этому поводу, то в ERP и учетных система есть огромный топик по этому вопросу. Вроде бы Oracle и MSSQL обсуждаем...
Дык давно уж вопросы ушли вдаль от ответов. Или наоборот :)

-- Tygra's --

Можно и отдельный топик. Но это уже будет 3-й топик с ООП БД

-- Tygra's --

автортбл. сотрудник(id, должность)+fk к физ.лицо (1-к-1 наследование) по id

для создания сотрудника
1) insert в контрагент
2) insert в физ.лицо
3) insert в сотрудник
везде id будет один и тотже (1-к-1)
это что бы ясно было.
Ну это один из способов, о множестве которых я говорил. Да, и так можно.

авторно все дело в том что я все эти xsp_Ins_xxx генерирую автоматом какая бы глубина наследования не была, поскольку они идентичны и хорошо формализованы, а в том получится ли это у вас, тигра, я не уверен...
Вы не уверены, что я в состоянии написать N процедур для вставки во все таблицы? Ну...... Я был летом у шамана, так даже он мне такого не сказал. А вы, видать, покруче-то будете, раз на расстоянии (или через интернет) определяете мои способности :)). Нашел я более 1500 ХП, которые точно я написал (там есть опознавательные знаки). Пока что смог, надеюсь, что смогу и больше :)

авторХм. Как-то так оказывается, что когда я на rsdn.ru цитирую местные утверждения про MS SQL - там просыпаются Sinclair или Merle и начинают говорить: "ну-ка, покажи, откуда ты это взял?" :)

А что, у вьюхи в MS SQL есть какой-то фиксированный план? Немного странная концепция, имхо...
Ну не знаю лично, есть ли план у вьюхи, но то, что если в выборках использовать вьюху, и не одну, то очень часто бывает, что вдруг слетают планы у ХП и именно из-за вьюхи, да и вообще непредсказуемо поведение. Ну это на достаточно сложных вьюхах, больше 2-х таблиц с некоторыми параметрами. На простых вроде ничего.

-- Tygra's --

Да я уж сам, по-старинке, руками :)) Тем более, что там есть еще кое-какая обработка, так что автоматически от силы 5% ХП можно сгенерить.

-- Tygra's --

А кстати, softwarer то сам как эту "задачку" решит? С юриками-физиками

-- Tygra's --