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

Alexey Shочень быстро выясняется, что у контрагента несколько адресов, набор из нескольких реквизитов и т п

т.е. эта таблица нужна только в том случаи если связь может стать один ко многим... а если это 100% 1 к 1, в этом случаи имеет свысл создавать таблицу addresses ?

traktor123 Alexey Shочень быстро выясняется, что у контрагента несколько адресов, набор из нескольких реквизитов и т п

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

Кот Матроскинда в любом случае лучше выделить имхо.
1. Нормализация и, соответственно, избавление от коллизий.
2. Единый интерфейс работы с адресами для разных сущностей - повышение повторной использумести кода.

да... но зато к этому усложнение создания выборки + более тормозная работа...

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

"Это зависит какая у Вас мышь"
(с) растаманская сказка

Если Вам неинтересно, что адрес может поменяться, то можете его занести в поле в таблице клиентов и т.п.

Адреса бывают разные - почтовый, юридический... Вы это учитываете?

Реквизиты - слишком широкое понятие, конкретизируйте. Например, банковских счетов может быть несколько.

реквизиты имеется ввиду юр адрес, счёт, название организации... кароче все реквизиты...

а как вы коннектили реквизиты и адреса ?
в одной таблице, со связью 1 к 1, со связью 1 к многим ???

Поделитесь опытом плиз, как кто вообще раблтал с адресами и реквизитами ?

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

нет, узнавать есть ли такой адрес я конечно небуду, мне такое ненужно, я про другое хотел спросить:
1. Есть контрагент - организации
2. У организации есть адрес, и реквизиты.
3. адрес - это физический адрес, а в реквизитах указывается юридический адрес.
и того получается что я к организациям подключаю аddresses, и RecvisitsView(вьюха из Recvisits + ещё раз подключённая addresses) - както некрасиво с этим вторым подключением addresses....
и ещё что делать если фактический адрес совпадает с юредическим - пустые поля оставлять или что ?

вопрос в том как правильно организовать связь контрагента с адресами и с реквизитами(в которых должен быть юр. адрес) ...???????????/

Dogen
1. У организаций бывает еще:
почтовый адрес (адрес доставки почты)
реальный адрес (точнее, чем физический :)
адрес доставки груза
2. Выясните, для чего Вам нужны реквизиты, и если только чтобы их распечатать (или поставить в счет), то не парьтесь и не расшифровывайте атрибуты реквизитов в отдельных таблицах.
3. Да? А зачем это Вам если у организации несколько реквизитов? В отчет выводить или на экран?.. А если одни реквизиты, то все это излишнее усложнение.
Вообще никто не мешает использовать left join и псевдонимы для многократного подключения справочника. Ну например один человек (запись из таблицы человеков) может занимать несколько должностей в организации, и эти должности суть колонки в таблице организаций.

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

ShtockУ меня есть таблица как я их называю почтовых адресов, таблица типов адресов (физический, юридический,адрес доставки) и таблица электронных адресов с указанием типа адреса (телефон, факс, e-mail). При этом есть таблица, позволяющая привязать электронный адрес к почтовому адресу (для раскрытия m:n).

А что делать с электронными адресами ???
какой у них формат - если у обычного адреса всё понятно: город, улица дом...
и всё это логическая единица,
то с электронным адресом - проблема тел к факсу и мылу неимеет никакого отношения... - это 3 разные логические единицы...
сейчас например телефоны у меня заданы просто тупо как поле телефон varchar2(100)....
что вы имеете ввиду под таблицей электронных адресов ??? -
таблицу контактов в виде тип(тел/факс/мыло)|строка ? или чтото другое
какой формат таблицы электронных адресов ?

и как электронный адрес привязывать к обычному адресу ???

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


вот и я несовсем это понимаю, но почти все говорят что так надо....
типа одинаковый интерфейс и всё такое....????


traktor123мне нужно 2 таблицы с адресами горизонтально развернуть чтобы их просмотреть можно было ???
и ещё куда мне пихать электронные адреса ??? (их наверное дофига может быть.....)
Ржевский, молчать!!![/quot]

хе хе хе неужели я там чтото неприличное сказал...

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


вот и я несовсем это понимаю, но почти все говорят что так надо....
типа одинаковый интерфейс и всё такое....????


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

а как нужно делать привязку таблицы адресов, если её использует много контрагентов, при отношении one to many ?

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

а если у меня скажем таблица контактные лица...
и несколько контрагентов, используют эту таблицу конт. лиц, тогда нужна связь one to many, т.е. ссылка должна быть не в контрагенте, а именно в контактных лицах на строку контрагента....
а если контрагентов много, то кроме ид строки контрагента нужно что ид таблицы контрагента ставить или что ? как такую связб делать ?

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
Встало на свои места?


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

Dogen
1. "Равноправное" и "подмножества" для вас родственные понятия?..


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

[traktor123]
т.е. у вас люди были контрагентами,
или если более правильно сказать контрагенты были подмножеством людей ?
[/quot]
- просто вопрос как у вас реализовано как п1 или п2, или както иначе ???

хотя впринципе мои п 1 и 2 это одно и тоже, если контрагенты = отношения...
контрагенты и отношения это одно и тоже ?