php - 一种更有效的为枢轴构建数据库的方法

Question

为了尽可能描述问题，我将详细说明实际情况: 该网站将允许用户添加 IP，以便根据 RBL 监控他们。在这样做的过程中，我一直在思考不同的方法来构建数据库，以尽可能优化大型 IP block 的效率，同时仍然可行。

该项目是建立在 Laravel 上的，我已经建立了一个数据库结构，其中包含:

table_a

Contains information about the IP we monitor.

• id (auto inc, primary)
• name (varchar, 128) Friendly name for the monitor
• ip (varchar, 16) The IP to monitor
• email (varchar, 128) An e-mail for notifications
• notifications (tinyint, 1) A toggle for notifications
• timestamps

-

table_b

Contains information about the RBL's we monitor against.

• id (auto inc, primary)
• url (varchar, 255) The URL for the monitor
• active (tinyint, 1) Toggle for whether we actively check toward it or not

-

table_a_b

A pivot table to maintain the status of each RBL in.

• table_a_id (int, 10) Foreign key to id on table_a
• table_b_id (int, 10) Foreign key to id on table_b
• listed (tinyint, 1) Whether or not the IP is listed on this RBL
• notified (tinyint, 1) Whether or not we've already notified the user

所以它目前的工作方式是，当添加一个 IP 时，它会将 IP 添加到 table_a 以及 (table_b 中的行数 * IP 的数量) 进入数据透视表。虽然添加它并不需要那么长时间 - 我看到的问题是添加/24 的 IP(256 个 IP)跟踪(当前)87 个 RBL 创建了总计 22,272 条记录。那是一个/24。/22(1024 个 IP)将是 89,088 条记录。对于单个用户来说，这是一个相当大的数量，我可以看到这将如何迅速破坏数据库性能。

我想到的另一种方法是在 table_a 上保留一个名为 listed_on 的列，它是其中列出的任何 RBL 的列表。该行将包含一些内容沿着 55|32|11 行——这很简单，可以在 PHP 中进行解析。尽管如此，对于大量的用户，我可以看到通过大量的字符串处理来降低 PHP 性能。

我是否错过了一个明显的解决方案，或者这两个(也许尤其是后者)是最好的选择？

干杯!

Answer 1

直接关系设计(而不是 table_a_b(ip, rbl, ...))是表 listed(ip, rbl) "ip IP is listed on rbl RBL”和notified(ip, rbl)“用户已被告知 ip IP 已列在 rbl RBL 上”。关系表旨在保存来自某些表特定谓词(由列参数化的句子模板)的真实命题(陈述)的行。很少有表格应包含一列或多列的每个可能值的行。

是否应该使用组合这些表的设计取决于您的谓词以及将它们应用于所有可能出现的情况所遵循的约束。例如，如果通知只发生在列出的 IP-RBL 对上，那么最好的可能是 ip_rbl(ip, rbl, notified) “ip IP 在 rbl RBL 中，NOTIFIED 是用户是否已被通知”。 (这里的权衡是更多的小表和更多的连接与更少的大表和更多的搜索。)

与非透视数据相比，PS 透视表通常不是操作和查询数据的最佳选择。它们适用于格式化最终输出给人类或在数据和元数据之间移动。参见 this news post . (我看到你的数据透视表是未透视的，因为 bool 列名不是数据值，即使它是 IP-RBL 上的总表。)