为枢轴构建数据库的更有效方法

Question

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

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

table_a

包含有关我们监控的 IP 的信息。

• id（汽车公司，主要）
• name (varchar, 128) 显示器的友好名称
• ip (varchar, 16) 要监控的 IP
• email (varchar, 128) 用于通知的电子邮件
• notifications (tinyint, 1) 通知开关
• 时间戳

-

table_b

包含有关我们监控的 RBL 的信息。

• id（汽车公司，主要）
• url (varchar, 255) 监视器的 URL
• active (tinyint, 1) 切换我们是否主动检查它

-

table_a_b

用于维护每个 RBL 状态的数据透视表。

• table_a_id (int, 10) table_a 上 id 的外键
• table_b_id (int, 10) table_b 上 id 的外键
• listed (tinyint, 1) IP 是否在此 RBL 中列出
• notified (tinyint, 1) 我们是否已经通知了用户

所以它目前的工作方式是在添加 IP 时，将 IP 添加到 table_a 中，并将(number of rows in table_b * number of IP's) 添加到数据透视表中。虽然添加它并不需要那么长时间 - 我看到的问题是添加 /24 个 IP（256 个 IP）跟踪（当前）87 个 RBL 会创建总计 22,272 条记录。那是一个/ 24。 A /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 在rbl RBL 上列出”和notified(ip, rbl)“用户已被通知ip IP 在rbl RBL 上列出”。关系表旨在保存从某些特定于表的谓词（由列参数化的句子模板）构成真正命题（陈述）的行。应该为一列或多列的每个可能值包含一行的表很少见。

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

与未透视的数据相比，PS 透视表通常不适合处理和查询数据。它们适用于格式化最终输出给人类或在数据和元数据之间移动。见this news post。 （我认为您的数据透视表是未透视的，因为布尔列名称不是数据值，即使它是一个在 IP-RBL 上总计的表。）