緩慢臨時表的複雜會計計算

我的任務是編寫一個複雜的開票和計費系統和報告。數據庫的結構是這樣的，即返回發票的總計和數字需要一個複雜的連接和計算串，這些連接和計算對於故障排除來說是麻煩的並且對錯誤高度敏感。緩慢臨時表的複雜會計計算

我沒有在整個報告系統中生成冗長而複雜的查詢庫，而是選擇使用臨時表來執行必要的計算，並將數字保存在我可以加入何時何地的記錄ID號旁邊需要。這使編碼系統變得更容易，但它也使數據庫明顯變慢，因爲每個需要使用此臨時表的頁面必須首先填充它。

總之，我有一個報告系統，必須能夠顯示一系列多張發票表中的計算數字。任何人都可以提供一個方法或解決方案的建議，這將簡化這個過程，而不會花費我的服務器速度？

2012-12-04 Tanoro

代碼緩慢可能是由您使用的查詢造成的。它們每個都對服務器有影響，我們通常會說微秒;但這些可以加起來。張貼您的代碼大量供參考 –

我已經考慮過了。如果我將生成此表的過程註釋掉，則每次都會生成正常的頁面生成速度。如果我打電話給我的臨時表，額外的4到6秒將被添加到頁面加載，生成大約7,000個計算記錄。這不是慢代碼。如果我需要幫助解決某些問題，我會添加一些代碼。現在，我要求一個更好的方法。 – Tanoro

我希望你有一個明顯的索引來匹配連接標準...只是要求... – DRapp

很難判斷你的描述過於籠統。

一個可能的解決方案：如果您在生成報告允許有點過時了，那麼你可以創建，而不是一個臨時的一個普通表，並使用事件調度經常用的所有信息填充它根據需要（例如每天一次或每小時一次）。

來源

2012-12-04 19:12:24 Geo

太通用了嗎？我不確定我可以做得更清楚些。我正在使用計算字段生成報告。獲得這些計算的過程太麻煩，無法在一千個地方完成。相反，我做到了一個地方，但每頁必須填充7,000多條記錄，打得太慢。什麼是更好的方法？就是那個問題。我認爲編寫一個可以完成你所描述的cron的cron，如果沒有更好的選擇，可以採取措施。 – Tanoro

緩慢臨時表的複雜會計計算

回答

相關問題