Добавьте все строки, умноженные на другую строку в другой таблице

Question

Добавьте все строки, умноженные на другую строку в другой таблице

0

Надеюсь, я смогу объяснить это достаточно хорошо. У меня 3 таблицы. wo_parts, workorders и part2vendor. Я пытаюсь получить себестоимость всех проданных деталей за месяц. У меня есть это script.

$scoreCostQuery = "SELECT SUM(part2vendor.cost*wo_parts.qty) as total_score 
                       FROM part2vendor 
                       INNER JOIN wo_parts 
                         ON (wo_parts.pn=part2vendor.pn)  
                       WHERE workorder=$workorder";

То, что я пытаюсь сделать, это каждая часть в wo_parts (под партией [pn]). Стоимость этого элемента находится в part2vendor (под номером детали [pn]). Мне нужно, чтобы каждая часть цены в part2vendor умножалась на количество, проданное в wo_parts. Способ, которым все 3 связаны, - workorders.ident = wo_parts.workorder и part2vendor.pn = wo_parts.pn. Надеюсь, кто-то может помочь. Вышеупомянутый script не дает мне то же самое значение, что и при добавлении калькулятором.

russell 07 дек. 2009, в 08:57

Источник

1

Вы говорите «продано за месяц», но в запросе ничего не говорится о датах.
Ivan Krechetov 07 дек. 2009, в 08:27
0

С финиковой стороны мне легко разобраться. В рабочей таблице есть столбец с названием date_out, поэтому остальная часть сценария сортируется по дате (месяц и год). У меня проблемы с добавлением частей. Каждая часть имеет строку в 2 таблицы. Один в part2vendor для цены, а другой в wo_parts для кол-во. Мне нужно, чтобы они были умножены вместе, а затем все части, которые соответствуют дате, сложены вместе (SUM).
russell 07 дек. 2009, в 09:18
0

WHERE date_part ('month', workorders.date_out) = '$ month' И date_part ('year', workorders.date_out) = '$ year' "; $ sRow = pg_fetch_array (pg_query ($ scorePartCostQuery));
russell 07 дек. 2009, в 09:19
0

Перед сценарием это. // диапазон дат публикации $ month = $ _POST ['month']; $ year = $ _POST ['year'];
russell 07 дек. 2009, в 09:20

Показать ещё 2 комментария

Теги:

php

mysql

postgresql

2 ответа

Ещё вопросы

Вы говорите «продано за месяц», но в запросе ничего не говорится о датах.
С финиковой стороны мне легко разобраться. В рабочей таблице есть столбец с названием date_out, поэтому остальная часть сценария сортируется по дате (месяц и год). У меня проблемы с добавлением частей. Каждая часть имеет строку в 2 таблицы. Один в part2vendor для цены, а другой в wo_parts для кол-во. Мне нужно, чтобы они были умножены вместе, а затем все части, которые соответствуют дате, сложены вместе (SUM).
WHERE date_part ('month', workorders.date_out) = '$ month' И date_part ('year', workorders.date_out) = '$ year' "; $ sRow = pg_fetch_array (pg_query ($ scorePartCostQuery));
Перед сценарием это. // диапазон дат публикации $ month = $ _POST ['month']; $ year = $ _POST ['year'];

Chris Travers · Answer 1 · 2012-10-01T00-21-00.000Z

Ключевая причина, по которой я мог видеть, что-то вроде этого, будет проблемой типа. Например, это может произойти, если вы используете FLOAT вместо NUMERIC, вы можете получить немного другой ответ. Это ошибка, которая слишком распространена, кстати.

Я бы рекомендовал дважды проверить вашу схему, чтобы убедиться, что вы используете NUMERIC по всей доске здесь. NUMERIC сумасшедший на PostgreSQL, он работает очень хорошо, и он правильно поддерживает операции произвольной точности. Если вы не можете изменить тип данных, введите свои поля в числовое значение в своем запросе.

Типы FLOAT (включая DOUBLE) - это двоичные числа с фиксированной точностью, и они не всегда соответствуют номерам оснований 10. ЦИФРЫ хранятся внутри базы в качестве базы 1000 (что означает 9 цифр на 30 бит), и это очень эффективно для преобразования в/из двоичного кода. Точность также произвольна, хотя она имеет максимум. Однако для финансовых продуктов максимальные значения или точность не являются проблемой с числовыми типами данных. Вы должны использовать их либерально.

Cedric · Answer 2 · 2009-12-17T19-59-00.000Z

Это не ответ, просто комментарий.

Почему бы вам не взять операцию sum/multiply вне инструкции SQL? Я знаю, это кажется глупым, потому что это увеличит строки кода и сложность script, но, imho, всегда хорошо держать коды и предложения SQL как можно дальше.

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