DogenСвязь конт.лиц и контрагентов, естественно, многие-ко-многим - через промежуточную таблицу.


и для каждого контрагента нужна своя промежуточная таблица чтоли ????,
или для каждого контрагента код в этой промежуточной табл указывается ??
как сопоставлять к.л. контрагенту1 а не контрагенту2 ?

а можно пример такой связи, например если есть
табл. контрагент1: idk1|inf_fields
табл. контрагент2: idk2|inf_fields
и табл конт. лиц: idKont | inf_Fields
как определить всех контактных лиц принадлежащих каждой строке 1-го или 2-го контрагенита

продолжение темы:

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

!!!2.!!! если есть множество контрагентов, и имеется множество таблиц, используемых таблицами контрагентами, тогда:
нужно создавать отдельную таблицу, в которой будут храниться коды контрагентов, и записывать эти коды контрагентов при создании очередных строк таблиц используемых контрагентами:

вот что я имею ввиду:

контрагенты:
места продажи
организации
.....

таблицы, которые используються контрагентами:

почтовые адреса
контактные лица(суррагатный ключ id|код контрагента)
электронные адреса(суррагатный ключ id|код контрагента)
.......

таблица с кодами контрагентов:

название контрагента|условный код
места продажи 1
организации 2
........


при создании очередной строки при связи one to meny в табл контактных лиц например,

нужно обязательно:
кроме генерации уникального id в пределах таблицы, внести ещё и значение в поле с кодом контрагента от к которому будет относиться данная запись например если мы создаём новое контактное лицо для места продажи, то нужно сгенерить уникальный ид и в поле с кодом контрагента добавить 1,
тоже самое для организаций сгенерить id и 2...

подскажите я на правильном пути или нет ????? исправьте сели я чтото не так понимаю
пасиба!!!

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

ShtockНу сейчас начнется... Почитайте Во имя уменьшения флейма и чуть-чуть прочитайте про теорию проектирования БД, плиз.

я пробежался по тому топику... даааа хоть у меня и не про бухгалтерский учёт дебиторов кредиторов и т.д...., но противоресия у меня в голове примерно такиеже...

Итак:
Исходные данные:
- таблицы контрагенты
- адреса (почтовые адреса)
- реквизиты(в них входит юр адрес)
связь контрагентов с адресами и реквизитами 1:1
Вопрос: как привязывать реквизиты и адреса к контрагентам ?
вар1: разнести всё на отделбные таблицы:
- контрагент(ы) в них ссылка 1:1 на адреса и ссылка 1:1 на реквизиты,
- в реквизитах ссылка 1:1 на адреса
вар2: промежуточный вариант:
- контрагент(ы) к нему добавляются в структуру записи поля адреса
и ссылка на реквизиты кот вынесены в отд. таблицу
- реквизиты - в структуру таблицы реквизитов добавлены поля с юр адресом
вар3: Никаких разделений на таблицы, т.е. просо в контрагентах дополнительно поля реквизитов и адреса.

и в моём случаи - когда уникальность реквизитов и адресов не нужна,
я всё больше склоняюсь к 3-му варианту:
+ 1. нет лишних тормозов(потомучто 1 табл всегда быстрее выберется чем несколько с-join-ных)
+ 2. Легче составлять запросы
+ 3. Более лёгкая схема изменения данных (одновременные изменения только в 1-й таблице)
Отрицательные моменты сводятся восновном к тому что это денормализация,
а также к логичности разделённой структуры и т.д.

помоему деление не нужно,
если я неправ поправьте меня плиз...

DogenА я так думаю, что в варианте 3 это можно и не называть страшным словом "денормализация"...
Единственное что меня сильно парит, так это то, что в 3-м варианте, в несколько таблиц с контрагентами (клиенты, места продажи, организации владельцы конструкций) нужно будет добавлять большое количество одинаковых полей адресов и реквизитов по 20-25 одинаковых полей...
ужас неужели такая жестокая реальность ??

Dogen traktor123 DogenА я так думаю, что в варианте 3 это можно и не называть страшным словом "денормализация"...
Единственное что меня сильно парит, так это то, что в 3-м варианте, в несколько таблиц с контрагентами (клиенты, места продажи, организации владельцы конструкций) нужно будет добавлять большое количество одинаковых полей адресов и реквизитов по 20-25 одинаковых полей...
ужас неужели такая жестокая реальность ??
и с какого перепою Вы решаете завести несколько таблиц контрагентов?.. чтоб жить хуже стало?
пожалуйста, не выдавайте свои идеи за советы посетителей форума :))

я и не выдавал...

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

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

Dogen
а контактные лица - это тоже контрагенты, или контрагенты это только организации ?

Подскажите, как правильнее сделаь таблицу контрагентов, точнее не как правильнее, а какие будут плюсы и минусы,
я вижу 2 потхода:
1. - создание таблицы с общими свойствами контрагентов
для конкретного типа сущностей юр или физ лиц, наследую общие св-ва,
т.е. создаю напр доп таблицы:
- клиенты(контрагент)
- филиалы(контрагент)
.............
2. - создание таблицы контрагентов, и в ней ссылки на табл юр. и физ лиц,
кот могут быть как заданы так и нет...., я несовсем понимаю этот потход....

посоветуйте как бы вы сделали и вчём преимущестыва 1-го и 2-го метода, может както ещё можно сделать ???

ShtockВам же дали ссылку на соответствующий топик. Там все разжевано, все плюсы и минусы. Уважайте время других людей!

я прочитал тот топик... ошибаетесь там сравнения этих двух потходов....

а у вас все люди из справочника люди являються контрагентами ?

ShtockНет, не все. Но если Вы внимательно (а я как посмотрю, чертовски внимательно) прочитали рекомендованный Вам топик, то должны были увидеть, что у меня имеется список ролей и отношений по субъектам (соответственно, контрагент-это отношение). ОДнако (не обижайтесь), если есть проблемы с опытом в проектировании БД, это будет тяжеловато, да и объяснять долго (времени нет, да и коммерческая тайна имеется).

вот что у меня получилось:

1. Таблица Люди - они же Persons - они же Kontragents - это общие свойства контрагентов физ и юр лиц
2. Две таблицы - уточняющие таблицу людей-контрагентов:
- физ лица
- юр лица
3. Конечные таблицы (унаследованные в данном примере от юр лиц)
- сети мест продажи(организации)
- клиенты
4. Контактные лица - это сокращённая форма физ. людей в кот нужно указывать фио и контакты(контакты не в прикреплённой таблице, а просто в полях телефон моб телефон мыло.... потомучто невижу практического смысла делать контакты one to many, проще вводить в заранее отведённые поля...
хотя я могу ошибаться...)
Вопрос к п4: инф. о контактных лицах должна хранится в таблице контрагентов + физ лица или в отдельной таблице, прикреплённой как many to one к контрагентам ?
5. отношения. - я понимаю что это таблица, которая по большому счёту должна фиксировть факты договорённостей между субьектами....т.е. по отношению к тому что я написал она прикрепляется к табл люди-контрагенты, и в ней указывается, кем данный контрагент приходится другим контрагентам, и с какими параметрами(сумма, договор, бла бла бла...)
7. роли - не вьехал чьто это пока абсолютно не вьехал нафиг нужны роли, если в табл отношения можно задать лбюое количество отношений....
развечто.... роли это и есть типы отношений(является сотрудником, доверенное лицо) ??????? но правильнее былобы это назвать типы отрношений...

Но если как вы говорите контрагент у вас - это отношение. тогда... непонятно что тогда таблица отношений.... и чтоже всё таки такое роли ???

Поправьте меня немного где я ушол не в том направлении... ???

Dogen traktor123а у вас все люди из справочника люди являються контрагентами ?
если я отвечу как у нас на самом деле, Вас это только запутает
недумаю что запутает, наоборот, всё станет на свои места!!! Истина есть и чем больше знаеш тем она ближе...

Dogen
Люди у нас являются списком аналитического учета, по сути равноправным со списком контрагентов.


т.е. у вас люди были контрагентами,
или если более правильно сказать контрагенты были подмножеством людей ?

Dogen
Такая структура прожила несколько лет, но я думаю что ее пора усложнить.


наверное не усложнить а упорядочить и добавить новые возможности...
Что привело вас к такому решению ?, зачем нужно добавлять возможности ?
что в старой схеме не работало так как нужно

Dogen
Встало на свои места?


направление правильное