2009-12-07 57 views
0

我希望我可以解釋這足夠好。我有3張桌子。 wo_parts,工作單位和part2vendor。我試圖獲得一個月內銷售的所有零件的成本價格。我有這個劇本。添加所有線在另一個表中乘以另一行

$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(在partnumber [pn]下)。該項目的成本部分2vendor(部件號[pn])。我需要part2vendor中的每個零件價格乘以wo_parts中銷售的數量。所有3個搭配的方式是workorders.ident = wo_parts.workorder和part2vendor.pn = wo_parts.pn。我希望有人能夠提供幫助。上面的腳本並沒有給我提供和計算器一樣的總數。

+1

你說「在一個月內出售」,但查詢中沒有關於日期的信息。 – 2009-12-07 08:27:33

+0

它的日期邊很容易進行排序。在工作表中有一列名爲date_out,所以腳本的其餘部分按日期順序(月份和年份)排序。我遇到的問題是部件的添加。每個部分都有2個表格中的一行。一部分是價格的二分之一,另一部分是價格的二分之一。我需要將它們相乘,然後將所有匹配日期的部分相加(SUM)。 – russell 2009-12-07 09:18:17

+0

WHERE date_part('month',workorders.date_out)='$ month'AND date_part('year',workorders.date_out)='$ year'「; $ sRow = pg_fetch_array(pg_query($ scorePartCostQuery)); – russell 2009-12-07 09:19:39

回答

1

這不是一個答案,只是一個評論。

爲什麼不在SQL語句之外進行和/乘操作?我知道,這看起來很愚蠢,因爲它會增加代碼行數和腳本的複雜性,但是,儘管如此,保持代碼和SQL語句儘可能遠離總是件好事。

+0

然後你把它放在錯誤的地方 – 2010-05-15 14:09:31

+0

不好主意。 ,如果有大量的行,那麼結果集在發送到客戶端時必須存儲在服務器的內存中,其次,客戶端必須在循環遍歷結果集時將其存儲在內存中。會導致性能問題,根據我的經驗,我從來沒有發現爲了減小結果集大小而添加邏輯的情況本身就是一個問題(API訪問t帽子邏輯有時是,但這是一個不同的問題)。 – 2012-10-01 01:25:03

+0

實質上,通過將這種邏輯從SQL中提取出來,會導致db和app服務器端*上的性能問題。 – 2012-10-01 01:27:01

1

我可以看到這樣的事情的關鍵原因是類型問題。例如,如果您使用的是FLOAT而不是NUMERIC,則可能會發生這種情況,您可能會得到一個稍微不同的答案。順便提一下,這是一個很常見的錯誤。

我建議再檢查一下你的模式,以確保你在這裏全面使用NUMERICs。 NUMERIC在PostgreSQL上非常強大,性能非常好,並且可以正確支持任意精度操作。如果無法更改數據類型,請在查詢中將字段轉換爲數字。

FLOAT類型(包括DOUBLE)是固定的精度二進制數,它們並不總是完全對應於基數10。 NUMERIC在內部存儲爲基數1000(意思是每30位9個數字),這對於從二進制轉換到二進制是非常有效的。精確度也是任意的,儘管它有一個最大值。但是,對於財務數據,最大值或精度不是數字數據類型的問題。你應該寬鬆地使用它們。

相關問題