Валерий Молчанов: тогда надо решить такую задачу
1. найти ID для первого IN (A0)
2. найти следующий ID для следующего IN (A1) ( select min(id) from table where id > A0 and flag = 'in') может вернуть NULL
3. взять сумму value всеx out записей между этими ID (select sum(value) from table where id between A0 and A1 and flag = 'out'
4. обновить A0 zapis'
5. удалить out записи between A0 and A1
6. commit
повторить для следующего A1 ID.
как повторить вопрос хороший, еслиб oracle яб написал pl/sql block
может в mysql есть хранимые процедуры?
тогда что то вроде (исходя из нашего псевдокода)
while isnull(A1, A0) > A0 loop
наш псевдокод
end loop
Валерий Молчанов: тут еще надо учесть, будут ли данные таблицы пополняться во время выполнения update. Если да, то надо уже по другому делать и не думаю что простым sql обойтись.
Валерий Молчанов: а они точно чередуются? те нечетные ID = out, четные = IN ?
ну тогда update будет примерно такой
update tableName
set value = value + (select Z.value from tableName Z where Z.flag = 'in' and Z.id = id+1)
where flag = 'out'
тут нужно поковырять конкретный синтаксис. смысл простой обнавляем данные таблицы используя копию этой же таблицы (мы можем назначать разные alias для одной и тойже таблицы) и связывем записи по вашему условию.
Ильдар Сарибжанов: яб скзал даже НУЖНО :)
Не вижу проблем заполнением "пустотой" те NULL
Да заранее описать все атрибуты производителя сложно, а если еще на каждом атрибуте завязана логика - то да это будет тяжеловато поддерживать. но есть несколько выходов. но не думаю, что у вас там все так сложно, по этому лучше все в одну таблицу.
k-2: Ну как говориться хозяин-барин. Хотя я очень сложно представляю, как вы будете расчитываться с поставщиком по ордеру если ордер будет сборной сольянкой из разных поставщиков.
Что касаем вашего вопроса, то можно просто просуммировать селектом. Можно подумать об агрегирующих таблицах которые аккумулируют суммы ордеров. Вешаете триггер на таблицу ордеров и ловите нужные события для дальнейшего отображения в агрегирующих таблицах. Добавился ордер - нашли нужную запись в агр. таблице и увеличили сумму на сумму ордера. Ордер удалили - уменьшили на сумму ордера. И тд. Если отчеты планируются на определенные интервалы: день, неделя, месяц, квартал и тд. Делаем свою агрегирующую таблицу на каждые интервал.
В случае с простым селектом - проигрываете по скорости выигрывете по размеру базы
Во втором варианте наоборот.
Да и с поставщиком на уровне позиции ордера я переборщил :) правильно поставщика оформлять в шапке ( в таблице ордера) иначе потом труба с бухгалтерией :)
Наверно повторюсь, но попытайтесь выписать на бумаге сущности (поставщик, товар, клиент, ордер) и написать отношения между ними. Например "у товара есть производитель", " у поставщика есть товар" (но не у товара есть поставщик :) "у заказа есть заказчик и поставщик" "у ордера есть позиции-товар" и тд
это даст примерное понятия, чем вы собираетесь оперировать. Так же стоит расписать "варианты использования" (смотрим UML) например "работник оформляет заказ", "работник отменяет заказ" , "возвращаем товар", "частично возвращаем товар". чем больше - тем лучше. Может случится так, что появятся новые сущности.
Одним словом - свобода творчества в ограниченном пространстве :)
k-2: Иногда люди так погружаются в свою задачу, что забывают выныривать и сверять с реалиями жизни:)
Про товар и поставщиков я сейчас отвечу очень простым вопросом. А если у вас 100 поставщиков одного и того же товара? Будете в таблицу товаров вводить сотню записей одного и того же товара? типа "картошка от Андрея", "картошка Антошки" и тд. Я уже представляю форму оформления заказа, разворачиваем дропдаун поле, а в нем 100 картошек :) А если у картошки еще 10 сортов...
Так как узнать, кто поставщик? Ну наверно каждый поставщик предлагает свои ассортимент товара и по своей цене. Наверно должно быть что то типа таблиц/ы каталога товара от поставщика?
Теперь про ордер и позиция_ордера. Как минимум заказ (ордер) имеет номер, дату, статус и поставщика, это все в собираетесь пихать в свой вариант таблицы? ну тогда не забудьте во все запросы где нужно получить номер ордера пихать DISTINCT, это не говоря о том, чтоб что то поменять в ордере :)
Вот еще вопрос НДС будем считать на уровне общей суммы ордена или по каждой позиции? Если по сумме всего ордера. то где будем хранить сумму НДС? Яб еще и о скидках наверно подумал (но тут я не очень в курсе) но я подумал бы :)
Про ценообразование наверно ничего очень толкового не скажу, это может быть очень простым, как у вас +25% и очень сложным типа "старость товара"+ "остатки партии" + сезонные скидки и скидки вечным клиентам и т.д.
Если я првильно понимаю, то TOP n возвращает первые N записей из выборки? Тогда хочу обратить внимание на один момент, как по мне важный :) если скажем у вас детали из выборки под номерами 5 и 6 будут иметь одну и ту же цену, то TOP 5 отрежет деталь номер 6, что не есть правильно.
Для решения таких задач, есть понятие RANK. Как это в Mysql - не знаю
Хотелось бы добавить, что join'ы для того и созданы, чтоб ими пользоваться. В большинстве своем, сервера баз данных имеют внутреннии оптимизатор, который пытается решить, как более правильно выполнить запрос.
Каждый раз, когда пишите SQL запрос к серверу, вы должны вспоминать, что SQL это такой язык, в котором вы "просите", что то, а серевер уже решает КАК это выполнить. Но не стоит указывть серверу, КАК достовать данные. Другимм словами, вы говорите ЧТО вам надо, но не КАК это делать.
MdaUZH: ну для этого и есть поле recept_id в моей таблице. и чтоб выбрать все те рецепты, в которые входит ХХХ продукт я напишу просто:
SELECT *
FROM Recept R,
Recept_Product P
WHERE R.ID = P.Recept_id AND
P.Product_id = XXX
Сервер с таким запросом даже не глянет в таблицу Рецептов если там нету нужного продукта, а в Вашей схеме глянет целых 9 раз для каждого рецепта в не зависимости есть ли в рецепте продукт или нет.
Если что, это не моя выдумка, это реализация связи "многие-ко-многим", подробней можно найти здесь habrahabr.ru/post/193380
MdaUZH: пусть будет так, я не настаиваю и если мы говорим о десятка рецептов, то база не подавиться.
Просто в Вашем варианте запрос выглядит так: "в первом рецепте есть продукт Х, нету? а во втором рецепте, а в третем?" т.е. вы будете "шерстить" все записи в таблице рецептов, вне зависимости есть продукт или нету. При моем раскладе Вы скажете "дай все рецепты где гарантировано есть данный продукт"
И сорри за офф-топик как бы :)
MdaUZH: обычно делают так, что разбивают таблицу Рецепты на несколько. Ниже приведу примерно как это может выглядеть и какие можно из этого извлечь плюсы:
Рецепты:
id | name | own_id |
Продукты_Рецепта:
id - уникальный идентификатор
nr - порядковый номер продукта в рецепте (может и не быть)
recept_id - идентификатор рецепта
product_id - идентификатор продукт (товара?)
quantity - кол-во продукта в данном рецепте (это как пример)
1 можно иметь больше информации о продукте в конкретном рецепте
2 Рецепт не ограничен 9 продуктами
3 В SQL запросах исчезнет индийский кода в виде
t.id = r.product_use_1 OR t.id = r. t.product_use_2 OR ........... t.id = r. t.product_use_9
Примерно так.
Кстати о таблице Комментарии там точно связь по product_id, а не по recept_id ?
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.