Есть 3 таблицы. Поставщик,Товар.Ордер. Как найти все ордеры поставщика?

Question

[k-2]

Разрабатываю организацию таблиц БД. Думаю создать следующие 3 таблицы.

Поставщики:
id
название

Товары:
id
поставщик id
цена

Ордер:
id
товар id

Нужно при выдаче товара показывать сумму всех ордеров у поставщика этого товара:
Товар: сумка
Поставщик: ООО "Завод сумок"
У этого поставщика было сделано заказов на: 500 750 руб

Посоветуйте как организовать таблицы БД? Не будет ли большой нагрузки, если при каджой выдаче товаров искать через все ордера сумму всех заказов поставщика?
Или лучше у поставщика сделать в таблице "сумма всех заказов" и приплюсовывать туда сумму при каждой покупке?

Или может быть есть другие варианты организации таблиц БД?

Answer 1

[Денис]

Как можно найти ордеры поставщика, если ты продаешь товар от разных поставщиков и в ордере товары от разных? И кто придумал такую замечательную структуру?

Comments

[Kovalsky]

Тогда логичней было бы вместо "У этого поставщика было сделано заказов на такую-то сумму" говорить "У этого поставщика было куплено товаров на такую-то сумму"

Я мало связан с миром бд, но мне кажется если есть возможность избежать ненужных вычислений (таких как сумма всех ордеров через select с двойным join'ом), лучше попытаться их избежать и, как вы сказали, использовать поле с суммой товаров для каждого поставщика.

[k-2]

Денис
"Как можно найти ордеры поставщика, если ты продаешь товар от разных поставщиков и в ордере товары от разных? "
в одном ордере может быть один товар только.
"И кто придумал такую замечательную структуру?"
Никто не придумал, я пока просто размышляю, чтобы построить правильно и без нагрузки на БД.
Скажите, как мне сделать так, чтобы при показе товара показывалась сумма всех заказов у этого поставщика?

[k-2]

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

Answer 2

[Immortal_pony]

Нормальная структура БД. Только дату оформления заказа не забудьте. Для упрощения задачи можете id поставщика также записывать и в таблицу заказов.

Не будет ли большой нагрузки, если при каджой выдаче товаров искать через все ордера сумму всех заказов поставщика?
Или лучше у поставщика сделать в таблице "сумма всех заказов" и приплюсовывать туда сумму при каждой покупке?

Нагрузка не будет большой при грамотно построенных индексах.

Answer 3

[kretsu]

Как по мне совершенно не нормальная структура:
Товар в принципе ничего не должен знать о поставщике.
Цена в таблице товара, цена чего? стоимость товара от поставщика или то, по чем мы будем продавать? не должно быть этого поля у товара
Ордер тоже не очень должен что либо знать о товаре.
По мне, структура должна быть примерно такой:

Поставщики:
id
название

Товары:
id
название

Ордер:
id
... (всякая общая фигная типа даты и тд)
поставщик id - если ордер может быть только от одного поставщика

Позиция_Ордера:
id
Ордер id
Поставщик id - если каждая позиция ордера может быть от различных поставщиков
Товар id
Кол-во
Цена за позицию

Это примерная структура и не касается вопросов образования цены , единиц измерения, амортизации товара и тд

Comments

[k-2]

| Товар в принципе ничего не должен знать о поставщике.
а товар мне у кого заказывать??? и как у позиции_ордера в таком случае появится id_поставщика ? ордер с потолка его придумает? Или все таки из таблицы товаров найдет id_поставщика? Я наверное чего-то не понял что вы имели ввиду, когда писали, что товар ничего не должен знать о поставщике... Где и как тогда эта информация хранится??

По поводу цены в товаре - то однозначно это цена поставщика. Цена на сайте вычисляется, НАПРИМЕР цена_поставщика Х 1.25 (+25%), процент можно выставлять отдельной таблицей, в зависимости от id_поставщика, id_категории, скидок итд.... Как то так.... Если честно я об этом еще не думал. Если есть интересные варианты реализации цены - буду рад их услышать. А цена поставщика все равно должна где то хранится, почему ей не хранится в самом товаре????

Ваша таблица почти ничем не отличается от моей. Вы просто "Ордер" заменили на "Позиция_ордера".

Вы мне лучше напишите, как мне быстро рассчитывать сумму всех "позиций_ордеров" одного поставщика.

[kretsu]

k-2: Иногда люди так погружаются в свою задачу, что забывают выныривать и сверять с реалиями жизни:)
Про товар и поставщиков я сейчас отвечу очень простым вопросом. А если у вас 100 поставщиков одного и того же товара? Будете в таблицу товаров вводить сотню записей одного и того же товара? типа "картошка от Андрея", "картошка Антошки" и тд. Я уже представляю форму оформления заказа, разворачиваем дропдаун поле, а в нем 100 картошек :) А если у картошки еще 10 сортов...
Так как узнать, кто поставщик? Ну наверно каждый поставщик предлагает свои ассортимент товара и по своей цене. Наверно должно быть что то типа таблиц/ы каталога товара от поставщика?

Теперь про ордер и позиция_ордера. Как минимум заказ (ордер) имеет номер, дату, статус и поставщика, это все в собираетесь пихать в свой вариант таблицы? ну тогда не забудьте во все запросы где нужно получить номер ордера пихать DISTINCT, это не говоря о том, чтоб что то поменять в ордере :)
Вот еще вопрос НДС будем считать на уровне общей суммы ордена или по каждой позиции? Если по сумме всего ордера. то где будем хранить сумму НДС? Яб еще и о скидках наверно подумал (но тут я не очень в курсе) но я подумал бы :)

Про ценообразование наверно ничего очень толкового не скажу, это может быть очень простым, как у вас +25% и очень сложным типа "старость товара"+ "остатки партии" + сезонные скидки и скидки вечным клиентам и т.д.

[kretsu]

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

Наверно повторюсь, но попытайтесь выписать на бумаге сущности (поставщик, товар, клиент, ордер) и написать отношения между ними. Например "у товара есть производитель", " у поставщика есть товар" (но не у товара есть поставщик :) "у заказа есть заказчик и поставщик" "у ордера есть позиции-товар" и тд
это даст примерное понятия, чем вы собираетесь оперировать. Так же стоит расписать "варианты использования" (смотрим UML) например "работник оформляет заказ", "работник отменяет заказ" , "возвращаем товар", "частично возвращаем товар". чем больше - тем лучше. Может случится так, что появятся новые сущности.
Одним словом - свобода творчества в ограниченном пространстве :)

[k-2]

kretsu:
| типа "картошка от Андрея", "картошка Антошки"
При чем тут товар. Это вопрос к категориям. Для этого нужно дерево категорий. А товары разные - "картошка от Андрея" - id=2, "картошка Антошки" - id=3. Это 2 разных товара. Они просто относятся к категории "картошка". Не путайте!

| А если у картошки еще 10 сортов...
конечно, но это уже идет в другой таблице параметров. У каджого товара может сущевствовать сколько угодно параметров - Это совсем другая таблица! В которой есть id_товара,параметр,значение.

| Теперь про ордер и позиция_ордера. Как минимум заказ (ордер) имеет
| номер, дату, статус и поставщика, это все в собираетесь пихать в свой
| вариант таблицы?
Ну вообще то не пихать а записывать. И где же этой информации хранится, если не в ордере???

| НДС будем считать на уровне общей суммы ордена или по каждой позиции?
по каждой позиции, в заказе могут быть разные поставщики, а в ордере(номере_ордера)-только один товар и соответственно один поставщик - значит и % наценка одна.

| Да и с поставщиком на уровне позиции ордера я переборщил :)
| правильно поставщика оформлять в шапке ( в таблице ордера)
| иначе потом труба с бухгалтерией :)
Наоборот!!! в заказе(в вашем случае это ордер) могут быть много поставщиков! как тут обозначить одного - никак! а в ордере(в вашем случае позиции_ордера) - только один товар - а значит один поставщик!

| "работник оформляет заказ", "работник отменяет заказ" , "возвращаем товар",
| "частично возвращаем товар". чем больше - тем лучше.
Это вообще проще простого - в ордере в графе "статус" - пишем его состояние (0 - не оплачен, 1-оплачен, 2-оформляется, 3-доставляется,4.5.6..... и т д)

Если бы вы прочитали мой вопрос, то возможно подумали как на него ответить.
Мне нужно, что бы при выводе товара показывалась сумма всех ордеров(позиций_ордеров) поставщика этого товара.
Вы же мне предлагаете - поставщика вообще не записывать в позицию_ордера, и в товар не записывать поставщика. Блин, но как же мне найти сумму всех ордеров???? так и не хотите отвечать..

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

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

Так есть что по теме ответить??

[kretsu]

k-2: Ну как говориться хозяин-барин. Хотя я очень сложно представляю, как вы будете расчитываться с поставщиком по ордеру если ордер будет сборной сольянкой из разных поставщиков.

Что касаем вашего вопроса, то можно просто просуммировать селектом. Можно подумать об агрегирующих таблицах которые аккумулируют суммы ордеров. Вешаете триггер на таблицу ордеров и ловите нужные события для дальнейшего отображения в агрегирующих таблицах. Добавился ордер - нашли нужную запись в агр. таблице и увеличили сумму на сумму ордера. Ордер удалили - уменьшили на сумму ордера. И тд. Если отчеты планируются на определенные интервалы: день, неделя, месяц, квартал и тд. Делаем свою агрегирующую таблицу на каждые интервал.

В случае с простым селектом - проигрываете по скорости выигрывете по размеру базы
Во втором варианте наоборот.