Ребят, тынцните почитать про оптимизацию и нормализацию БД плиз, так что бы не столько на русском, сколько "по-русски" было написано.

Задача вроде бы тривиальная - как спроектировать БД, но я застрял на таком пункте.

Есть данные, которые конечно же надо вносить в БД.
ПЛАН:
1. Код
2. Цена
3. Наименование подрядчика
4. Период (дата)
5. Номер договора.

+
Вроде все понятно. Далее задача разделить по подрядчику данные. Скажем есть один подрядчик, который относится к группе Заказчик, а все остальные к группе - Исполнитель. В базе данных это можно сделать добавлением поля типа ContactorType:

+
И потом задача - отобразить отчет вида:
Код Подрядчик (Заказчик)Цена (Заказчик) Подрядчик(Исполнитель) Цена(Исполнитель) Период Договор1 Ромашка 200 000 Одуванчик 210 100 фев-2012 ДОГ-1456
Что означает, что в запросе будет обращение к таблице Plan два раза через Left join, т.к. не всегда будут одновременно для одного договора или кода занесены и исполнитель и заказчик.

Другой вариант, это увеличить количество столбцов в таблице Plan для заказчика и исполнителя - добавить еще один Price_zak и еще один Contactor_zak_id:
+

Внимание вопрос : как лучше спроектировать БД и при/до каких размеров имеет смысл пользоваться одним или вторым вариантом.

Где будет лучший выигрыш по времени/затратам ресурсов сервера?

Спасибо!

Модератор: Тема перенесена из форума "Microsoft SQL Server".

iljynotricky,

у вас же исполнителей может быть несколько, вы до каких пор собрались таблицу расширять?? К заказчику я так понимаю привязка 1-[0..1], так? Тогда инфу о заказчике лучше в таблице с заказом (планом? вот этой сущности я не понял) хранить, в виде nullable полей, а исполнителей вывести в отдельную таблицу с привязкой по ФК.

Ну сущность План - неважно как назвать на данном этапе. Пока что не важно.

Исполнитель и сумма по исполнителю могут быть внесены без указания заказчика и суммы по заказчику.
Условно говоря - Код и Период будут являться составным ключом. Если еще добавить, что Код - это ссылка на список кодов, а не varchar.

notricky,

Исполнитель на каждую строчку (каждый код и период) может быть один. Как и заказчик.

И все-таки вопрос был по соотношению ресурсы/скорость в случае с двумя джойнами по одной и той же таблице или без джойнов.

iljynotricky,

формулируйте задачу четче.


notrickyСкажем есть один подрядчик, который относится к группе Заказчик, а все остальные к группе - Исполнитель

как понимать? Сколько может быть этих "остальных" и к чему они относятся?

Вы правы, наверное моя ошибка.

Задача: иметь возможность вывести как в таком формате:
1.
КодПодрядчик (Заказчик)Цена (Заказчик)Подрядчик(Исполнитель)Цена(Исполнитель)ПериодДоговор1Ромашка200 000Одуванчик210 100фев-2012ДОГ-14562Одуванчик3 510 100янв-2012ДОГ-10003Ромашка9 200 000фев-2012ДОГ-1000
Так и в таком
2.
КодПодрядчикЦенаПериодДоговор1Ромашка200 000фев-2012ДОГ-14561Одуванчик210 100фев-2012ДОГ-14562Ромашка9 200 000фев-2012ДОГ-1000

Как при этом адекватно спроектировать БД: а) писать все в одной таблице б) писать по структуре "шапка"-"документ".

В таблице, в зависимости от проекта, куча может быть соотношений заказчик-исполнитель.
Условия:
1. На одну строку Код+Период - не более одного заказчика и не более одного исполнителя.


2_ Dmitry Sibiryakov , а почему собственно нет? Действительно, заказчиков и исполнителей-то будет не много, а вот самих строк в таблице План будет крайне не мало. И джойн по таблице, что бы вывести в строку заказчик-исполнитель дважды, как я понимаю, не тоже самое, как его отсутствие.

iljynotrickyУсловия:
1. На одну строку Код+Период - не более одного заказчика и не более одного исполнителя.

Если это жесткое и неизменное условие предметной области, то можно действительно писать в одну строку инфу и о заказчике, и об испонителе. Но я бы не стал. Причина очень простая: а если нужна какая-то статистика по подрядчикам, при этом в некоторых договорах они выступают как исполнители, а в некоторых - как заказчики? Я бы сделал разные строки, а ПК сделал (Код,Период,Тип подрязчика). Собрать инфу по одному коду-периоду моно без всяких джойнов банальной группировкой. А хоть бы и соединением - если идет поиск по близким значениям индекса, то разницы вы не почувствуете.
Спасибо, тоже стал думать в эту сторону.
А можете пример кода такой группировки?

И можете подсказать какой индекс создать?

нет?

SERG1257Dimitry Sibiryakov Какие ресурсы, какая скорость, о чём вы? Только не говорите, что Вы всерьёз рассчитываете
на миллионы заказчиков и миллиарды исполнителей. Делайте правильно, об оптимизации будете
заботиться потом.+1 (и даже больше чем один)

notricky у вас в голове каша из предметной области. Сделайте ее прозрачной, что откуда берется и куда затем деется (
классический список сущностей и связей между ними, список действий над базой плюс определенный сейчас плюс возможно потребуемый)
В человекочитаемых формах будет там один Left join или два особого рояля не играет.да что за манера отвечать на те вопросы, которые не задавались? Вы самый умный? Тогда подскажите в контексте моего вопроса ответ. Если нет - советовать не просили.