Alexey ShА причём здесь бухгалтерия? У бухгалтерии нынче одна задача - сдавать отчёты в налоговую. А задача - управлять бизнесом.А отчеты - они откуда берутся?

DogenНе путайте контрагента с контрактом, вполне возможна работа с поставщиком как с поставщиком и одновременная продажа ему вашего же товара, и еще и бартер, и отчетность нужна как сводная так и по каждому контракту отдельно.Мне кажется, я ничего не путаю. "Контракт" - это то же самое, что "договор". А кроме "контрагента" и "контракта" еще может быть "сделка", о которой шла речь чуть выше, объединяющей сразу множество контрактов и котрагентов. И необходиомсть иногда перебрасывать средства с одной "сделки" на другую, для чего необходимо анализировать общую картину по совокупности "сделок", в которых завязан конкретный контрагент.
Никто не спорит, что поставщик МОЖЕТ быть одновременно быть покупателем. Конечно, может, именно это я и пытаюсь подчеркнуть. И для анализа совокупности разнородных операций с одним контрагентом удобно иметь ЕДИНЫЙ справочник контрагентов, а не отдельно справочник покупателей и справочник поставщиков. Именно эту мысль я и пытался подчеркнуть. Если Вы с этим не согласны, то объясните, почему. А если согласны, то смысл Вашей реплики я не понял, уточните его пожалуйста.

DogenВсе упирается в достаточную глубину проработки предметной области - если вопрос стоит так как в процитированном, то нужен список контрагентов, список контрактов... А кто их них поставщик кто покупатель - зачем это надо? А это надо в бизнес-логике, чтобы не давать доступ к тому к кому не надо.Значит, Вы все-таки согласны с тем, что справочник контрагентов должен быть общим? Тогда о чем мы спорим?
Есть только еще один нюанс. Покупатели и поставщики могут иметь РАЗНЫЕ атрибуты. Например, для покупателей может указываться индивидуальный процент скидки, который не имеет никакого смысла для поставщиков. Если мы используем единый справочник контрагентов так же и для ссылки на комиссионеров, то для комиссионеров могут оказаться существенными свои специфические реквизиты. Например, предельные размеры товарного кредита, предоставляемого по договорам комиссии конкретному комиссионеру (или какие-либо другие характеристики степени доверия). Присобачивать вообще все возможные реквизиты вообще ко всем контрагентам - неудобно и нерационально. Одновременно не хочется отказываться от идеи иметь единый справочник котрагентов.
Поэтому мной и предлагается убить одним выстрелом двух зайцев, заимствовав идеи из ООП касательно наследования и приведения типов. Почитайте обсуждение сначала, возможно, Вы что-то пропустили? Если нет, то я так и не понял, против чего Вы выступаете и за что?

2 LSV. Разумеется, специфические реквизиты могут быть у договора, у раздела договора, у пункта договора, но они могут быть и у контрагента. Если с одним и тем же котрагентом заключается множество договоров комиссии, то при появлении нового договора нужно каждый раз заглядывать в другие договора, чтобы узнать параметры степени доверия к данному комиссионеру, чтобы еще раз их ввести? А не проще ли хранить эти параметры привязанными именно к самому комиссионеру, ведь степень доверия - не к договору, а именно к комиссионеру? Однако, они вполне могут существовать и как атрибуты договора комиссии. Тогда атрибуты комиссионера выступают как значения по умолчанию для заполнения аналогичных атрибутов нового договора. Если степень доверия к комиссионеру со временем изменяется, то можно изменять значение атрибута комиссионера. Тогда для новых заключаемых в будущем договоров автоматически будут проставляться новые значения, а в старых будут продолжать фигурировать старые.
ПМСМ, один раз на все случаи жизни невозможно определить, куда цеплять атрибуты - к контрагенту или к договору. У одного контрагента может быть множество договоров. В одном договоре может быть завязано множество контрагентов (многосторонние договора, например). И выше я показывал (на примере Гарант-Сервис), что даже в одном и том же договоре один и тот же котрагент может фигурировать одновременно в нескольких ипостасях (конкретно как поставщик услуг и как поставщик продукта). Связи многие-ко-многим, довольно навороченные.

Своей постановокй вопросов ребром mazzy помог мне переосмыслить некоторые глобально-концептуальные вещи. Я серьезно пересмотрел свои позиции по целому ряду вопросов. Хотя, возможно, мое мнение и не совпадает со мнением mazzy... :)
Сейчас я пытаюсь выстроить ту кашу, которая в итоге получилась в моей голове, в единую стройную систему. На это уйдут некоторые усилия и время. Я постараюсь написать статью, когда созрею.

mazzy GaryaЯ постараюсь написать статью, когда созрею.
С удовольствием опубликую на своем сайте, если позволишь.Позволю, конечно. Только рано еще делить шкуру неубитого медведя... :)

ShtockУ нас практически все хранится в едином справочнике в силу специфики бизнеса (персонал, отделы, контрагенты, банки и др). Но в тоже время надо знать где остановиться -)? Например, если нас не интересуют сведения по физическому лицу-директору компании ААА, то мы записываем его в таблицу Должностные лица, которая привязана к таблице Юридическое лицо (описывающей доп. атрибуты юриков). Если интересно, то создаем отношение Является директором и связываем физика и компанию ААА. Как уже говорилось ранее, мы используем понятие Роль(банк, депозитарий, паевой фонд и др.) и Тип (юрик, физик, прочее). Соответственно есть таблицы дополнительных типовых и ролевых атрибутов. Есть отношения типа "Роль-роль", "Роль-субъект", "Субъект-субъект". Кстати, есть таблицы "Ролевое наименование" и "Типовое наименование". Часто оказывается, что в сложных организациях до черта этих наименований.
Я в осознании некоторых вещей ушел, как мне кажется, гораздо дальше общепринятых представлений реляционной теории и ООП. Последняя мысль, которая меня в этом направлении недавно осенила - это концепция "типоэкземпляров". То есть, хранение метаданных об экземплярах объектов в самих объектах. Это принцип, заложенный в природе. В ООП есть четкое разделение на понятие "класс" и "экземпляр класса". Класс - это описательная часть, метаданные. Экземляр - реализация класса, конкретный объект. Но он внутри себя не содержит описания своего класса, метаданные существуют отдельно.
А теперь взгляните, как работают механизмы наследования в природе. От родителей возникают дети - новые экземпляры. Где метаданные детей? В родителях? Тогда почему дети продолжают нормально функционировать после смерти родителей? Метаданные лежат в ДНК самих детей! Каждый биологический объект является одновременно классом и экземпляром класса! Классом он является для своих детей, экземпляром класса - для своих родителей.
Но экземпляр отличается от класса тем, что он содержит конкретные данные!
Если совместить эти положения с концепцией единой иерархии хранимых "типообъектов", наследуемых от одного (в рамках данной системы) базового "типообекта-бога", в котором заложены механизмы хранимости, наследования и т.д. и т.п., да присовокупить к этим концепциям идеи версионности и журнализации как объектов, так и бизнес-логики, до которых я дошел ранее , то получается такая грандиозная конструкция... Аж дух захватывает! Первая мысль, которая пугает в этом подходе, это необходимость многократного копирования метаданных, которые по большей части мало отличаются у разных экземпляров (или даже не отличаются вовсе). Но этот нюанс я уже продумал - он очень изящно обходится. Хранение метаданных типообъектов вполне можно оптимизировать.
Продуманы нюансы наследования только некоторых свойств. Например, цвета волос в природе. При этом приобретенные природным "типообъектом" некоторые навыки - умение играть на фортепиано, привычка курить, владение шпагой - по наследству не передаются (возможно, только наклонности подобного плана).
Механизм наследования, в котором участвуют не только классы, но и экземпляры классов, могут наследовать не только метаданные, но и сами данные! Не пугайтесь, это в общем случае, можно отказаться от использования этой фичи. Но можно сделать данные родителя default-значениями для детей. У некоторых детей значения полей класса можно и изменить затем в нужную сторону (ну всё как в природе!). :) А можно изменить и бизнес-логику. Причем, можно изменить бизнес-логику с распространением этих изменений на всех потомков, либо без такого распространения, либо с распространением этих изменений только на часть потомков (а у остальных метаданные останутся СТАРЫЕ!).
Уже продуманы некоторые аспекты реализации DRI.
Только, ради бога, давайте не будем обсуждать эти вещи в этом треде. Во-первых, там очень-очень много нюансов, над которыми я еще продолжаю думать - они требуют дополнительного осмысления. Во-вторых, по объему эта информация врядли уместится даже в статью. Получается уже нехилая книжица. А мне нужно еще время. Я еще окончательно не созрел, чтобы выкладывать всё в виде единой стройной концепции. Сорри... :)