Ну по поводу культового "физика-юрика" где ясно и подробно вроде бы все объяснено,но в нашей системе я завел бы этого дилера как юрика,потом ввел бы всех клиентов, сделал роль "Дилер" и присвоил бы дилеру эту роль, сделал бы тип отношения "Является клиентом дилера", причем для отношения бы ввел ограничение "Дилер"-"Клиент" и наконец, для каждого клиентал создал бы отношение с этим дилером посредством этого типа отношения. Структуру таблиц и идею для системы отношений ищите в этом топике + в моих древних других с человеком с ником tractor123.В сделке с дилером я бы указывал id дилера,так как все равно Вы не узнаете, кому из них какую продукцию он отдал (это его внутреннее дело), в сделке с клиентом-id клиента- ведь нет никакой разницы между ними.

Если же вдруг дилер скажет Вам,какие кому он товары отдал,то практически ничего с точки зрения бд не меняется: есть таблица-шапка заказа (в ней пробить id того,кто действительно покупатель - дилер или одиночный клиент), есть таблица деталей заказа с указанием проданных/купленных номенклатурных позиций услуги/товара и их количественных характеристик, добавьте туда код субъекта (неважно,кто он-дилер или непосредственно покупатель) и да будет счастье (всех и раскидаете).С точки интерфейса можно все изящно оформить: для каждого дилера по таблице отношений можно выбирать всех принадлежищих ему клиентов и при забивании распределения товаров показывать только их.
Есть правда один вопрос,над которым надо бы подумать.
Пусть есть уже известная нам таблица деталей заказа, пусть есть 2 товара, 1 дилер и 2 клиента.
Даннные в табличку заказа можно вбить 2-мя способами:

Способ 1
Товар 1 Клиент 1 5 штук
Товар 1 Клиент 2 2 штуки
Товар 2 Клиент 2 2 штуки

Таким образом, в таблице деталей при нескольких товарищах не видно общей суммы если не получать ее суммированием

Способ 2
Товар 1 Дилер 7 штук
Товар 2 Дилер 2 штуки
Товар 1 Клиент 1 5 штук
Товар 1 Клиент 2 2 штуки
Товар 2 Клиент 2 2 штуки

А теперь быстро видна вся хитрая подноготная структура заказа.

Хотя это такое хитрожо$*ое кэширование может и навредить





P.S. Главная проблема-откуда возьмете клиентов дилера и каком он между ними гоняет товар,прямо промышленный шпионаж какой-то нездоровый.

TO guest_20040621:это наверняка надо для модной сейчас очередной трех-буквенной технологии - анализ деятельности конкурентов (это сейчас в crm обожают пихать).

СОбственно вариант Кота Матроскина и мой - одна фигня,главное по id контрагента вычислить кто он, дилер или клиент (типа роль).Правда я вот с трудом вижу,как понять кто контрагент в сделке:дилер или клиент (ведь он может быть и тем и тем),если об этом дополнительно не сообщается.Может я купил 5 литров мяса для себя :) -я клиент,и 100 - друзьям - я уже дилер.Поэтому тогда в сделке надо держать еще и роль субьекта, с которой он выступил в данной сделке).

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