我有原始日誌長達一週的wifi功能的設備與我研究所的無線路由器的關聯。 截至目前我打算把它放在一個數據庫，如下所示：
一個大的有表列：評論（寫一次）數據庫設計存儲網絡信息
的數據庫將僅被查詢以在一週內檢索特定設備的連接歷史記錄。
記錄變成一週後，它將被刪除或移動到其他地方。
現在設備的數量可能在800到2000之間。因此，對於每個設備都有一個單獨的表，或者它沒有意義嗎？
無線路由器的數量約爲< 40我相信。
最後，一週的日誌將小於1 GB。
我現在正在使用一個SQL數據庫（真的堅持這一點，不想改變，但請提一個替代品，如果它有顯着的改善）。
現在我的問題是，（一個表）方法有效的時間明智的 - 查詢得到執行並返回結果的時間。 空間和冗餘是沒有問題的，只是查詢返回的速度*。
也評論可以採取什麼措施/修改，以使這樣一個系統可擴展。
* 它不應該如此複雜，難以維護。
我看不出有什麼理由需要將其分解。如果您的唯一目的是用路由器和設備地址存儲日期時間戳，那麼您確實沒有其他需要做的事。一張桌子就可以做到。
正常化背後的整個想法（是的，我在這裏簡化它）是，你不應該一次又一次地在多個表中重複相同的數據。
例如說你想存儲此：
Router | Mac Address | Device Type | IP Address | Device Model | Device Serial Number
這將是更好的有指定了這一切，有一個路由器/設備表中特定DeviceID和一個有說
DeviceID | TimeStamp
你會這樣做，所以你不必每次重複每個日誌條目的所有信息。
希望這有助於...
但隨着表格大小的增加不會使用DeviceID查找|時間戳變慢了？有什麼辦法呢？ – digvijay91
您是否正在考慮創建多個表的這個選項。我認爲你應該真的只需要簡單的1表設置。 – logixologist
2000設備X 40路由器= 80,000行X一週7天只有560,000行。 SQL仍然在這個級別上打呵欠......如果你保存了記錄，並且你每週增長了0.5M ......這可能會變得很快，你可能不得不看一些索引。恕我直言，保持簡單先生... – logixologist
由於您存儲和刪除數據的方式，我的建議是創建一個由時間戳分區的單個表。這種方法的好處：
最重要的是，您可以使用專門設計的索引對多列進行索引，以便爲您的查詢快速檢索數據。由於沒有DDL，樣本數據或查詢（可能是後續問題），這些索引看起來像是不可能說的。 使用CLUSTERed索引也可以提供幫助，因爲您有靜態數據（WORM）。
如果您需要在INET類型的真快，查找（如果內置的網絡數據類型是不夠快即是），他們有一個看看IP4R數據類型：http://pgfoundry.org/projects/ip4r/
感謝您指向分區。以前不知道。可能在版本2中使用。 – digvijay91
分區的最大好處不一定是性能，它是用於維護數據，又名分區等。 – bma
相信在KISS方法 - 保持簡單先生。我不能想到任何原因，你需要用多個表格來複雜化它。 – logixologist