Таблица контрагентов в БД

[gray136]

Уважаемые специалисты помогите разобраться новичку. Есть задача сделать БД организации продаж сырья (щебень, песок и т.п.) сделал таблицы, установил связи но возникла следующая проблема: при организации работы результирующая таблица - реестр отгрузок информация в который заносится из справочников (вид сырья, тема сырья, сырье) здесь все четко и прозрачно, а дальше самое интересное - необходима база контрагентов тонкость в чем, в том что один контрагент может быть и покупателем и перевозчиком и поставщиком, дальше пришла мысль и сделал для каждого типа контрагентов свою таблицу (для перевозчиков - carriers, для покупателей - buyer и т.д.) но в этом случае если контрагент является и покупателем и перевозчиком то нужно заносить одного контрагента с одинаковыми данными в две разные таблицы и в случае изменения есть вариант где то не поменять данные (в какой то из таблиц) если же брать одну таблицу для всех контрагентов то поле с названием контрагента будет называться Partner а в результирующем реестре будут поля и buyer и carrier поэтому не знаю как установить связи, еще нюанс у каждого перевозчика есть свой автопарк который необходимо выделить в отдельной таблице carrier. И собственно вопрос как правильно реализовать структуру БД? P.S. БД прилагаю)

[satka]

Ни хера не понял в этой смеси ключевых полей, надо бы вам ещё подумать над структурой БД

[gray136]

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

[Woodlin]

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

[gray136]

Это можно сделать и в одной таблице - добавить поля логического выражения определяющего контрагента к тому или иному типу, но в результирующей таблице (реестре событий, а точнее отгрузки сырья) есть по меньшей мере два поля в которые будут вставляться данные из этого справочника по определенным требованиям, например контрагент "бронта" является и покупателем и перевозчиком, в справочнике наименование у него одно (поле partner) а в результирующей таблице одно поле buyer а второе carrier. названия полей разные а данные одинаковые и должны отвечать результату отбора по логическому выражению т.е. для выбора в поле carrier контрагент должен быть перевозчиком

[Woodlin]

Не могу посмотреть Ваш файл, у меня оффис 2003.
Если в справочнике контрагентов у Вас есть поле счетчик, то в реестре событий можно в полях перевозчик и покупатель ставить просто значение счетчика и всё.

[gray136]

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

[Woodlin]

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

[gray136]

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

[satka]

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