2012-03-08 44 views
1

我正在開發基於用戶日誌分鐘數的功能的zend項目。它需要能夠根據日期範圍生成報告。我希望有人能幫助我找出處理存儲信息的最佳方法。如何在MySQL數據庫中根據日期爲用戶構造數據

我正在使用用戶表來處理所有重要的配置文件信息。我可以想象最好的情況是將這個鏈接到另一個表格來跟蹤分鐘......我只是沒有圍繞它應該如何佈置我的想法。我已經看到一些頁面建議在日期中使用數據庫中的列,但在我看來,它很快就會變得難以管理。

隨着目前的網站在1500個用戶和多個用戶每天提交...即時通訊只是不知道如何編號去它。

任何幫助將是偉大的。 感謝

+0

嗯,你可以擴展你的意思是用戶的日誌分鐘?他們是手動執行此操作還是「花費在網站上的時間」? – Aatch 2012-03-08 01:42:28

+0

它是手動輸入的。實際上,導師在任何一天都會輸入他們的學生閱讀的時間。 – Cpage 2012-03-08 02:09:11

回答

0

一種方法的基礎上,我認爲你正在尋找:

創建包含USER_ID FK,一個START_TIME和END_TIME一個USER_SESSION表。每次用戶啓動和結束會話時,都會向此表中寫入新行。您可以在登錄時獲取這些User_ID和Start_Time,並在會話結束或用戶註銷時抓取End_Time。

現在你已經有了一個[1500用戶] x [每天會話數]的歷史表,我可以稱之爲大型的,但並非難以想象。 (尤其是查看它是如何正確編制索引的等)。您可以針對該表運行查詢,比如SELECT User_ID,SUM(End_Time - Start_Time)等等,以針對您需要的任何日期範圍。

要控制表大小,您可以依次存儲這些聚合值(User_ID,MMYY,Num_Minutes)並在某些設置的計劃中截斷源表。儘管如此,存儲計算的字段可能不會比擁有標準化數據更好。所以,也許不要走這條路線,直到你確定源表的大小是一個大問題。

只是衆多方法中的一種,並且爲了清晰起見而過於簡化。

+0

這是有道理的。這也解釋了我計劃在晚些時候發佈的部分功能,所以也要感謝。 – Cpage 2012-03-08 02:15:52

+0

對於你的另一個問題,如果我可能......我對這個大小的數據庫有點新,你會說數據庫變得「太大」了?我知道這一切都將取決於文件大小,服務器等我只是尋找一個一般的想法,當你可以看到它導致問題。 – Cpage 2012-03-08 02:18:21

+0

100,000+行應該沒有問題。關鍵的考慮因素是設計良好的表格(您只需存儲必要的鍵和不要多餘的數據)和索引(根據您打算查詢的字段選擇適當的索引)。當然,服務器速度和文件大小很重要,但這不是十分之九會燒九分之一。 – LesterDove 2012-03-08 02:41:36

相關問題