我有原始日志长达一周的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