Redis vs MySQL 用于简单数据库

Question

我想创建一个简单的数据库，该数据库必须存储节点、它们的功能和地址，以便在出现问题时通知。最初我在考虑使用一个简单的 SQL 数据库：

CREATE TABLE IF NOT EXISTS push_notifications (
  node text NOT NULL,
  functionality text NOT NULL,
  address text NOT NULL,
);

其中节点和功能可以有多个地址，N 到 N。这种获取地址的方式我将执行以下两句话：

SELECT address from push_notifications where node=XX and functionality=YY;
SELECT node, functionality from push_notifications where address=XX ORDER BY node, functionality;

但是看了一点之后，我有几个疑问：

• 对于最初不会超过 10000 个条目的数据库可以吗？
• 我是否应该使用规范化的方式来组织表，即一个用于节点，另一个用于功能，另一个用于地址以及在 SELECT 中使用 JOIN？那么，如何自动删除不再链接的表中的条目，即没有功能且没有端点的节点？
• 我是否应该使用像 Redis 这样的简单数据库引擎，将键设置为节点功能（字符串和值是地址列表），并将另一组键设置为端点（哈希）？

我想补充一点，我将使用 Java 来处理对数据的访问。

感谢您的帮助。我真的很感激并建议什么是做这种事情的最佳方式。

编辑：选择多个简单表格的选项（我认为还可以）

 CREATE TABLE IF NOT EXISTS node (
   id integer PRIMARY KEY AUTOINCREMENT,
   iri text NOT NULL,
   UNIQUE(iri) ON CONFLICT IGNORE -- ON CONFLICT REPLACE
 );

 CREATE TABLE IF NOT EXISTS functionality (
   id integer PRIMARY KEY AUTOINCREMENT,
   name text NOT NULL,
   UNIQUE(name) ON CONFLICT IGNORE -- ON CONFLICT REPLACE
 );

 CREATE TABLE IF NOT EXISTS address (
   id integer PRIMARY KEY AUTOINCREMENT,
   url text NOT NULL,
   UNIQUE(url) ON CONFLICT IGNORE -- ON CONFLICT REPLACE
 );

 CREATE TABLE IF NOT EXISTS push_info (
   node integer NOT NULL,
   functionality integer NOT NULL,
   address integer NOT NULL,
   UNIQUE(sensor, endpoint) ON CONFLICT IGNORE, -- ON CONFLICT REPLACE
   FOREIGN KEY(node) REFERENCES node(id) ON DELETE CASCADE
   FOREIGN KEY(functionality) REFERENCES functionality(id) ON DELETE CASCADE
   FOREIGN KEY(address) REFERENCES address(id) ON DELETE CASCADE
 );


 SELECT address.url as address
   FROM address
 INNER JOIN push_info
     ON address.id = push_info.address
 INNER JOIN node
     ON node.id = push_info.node
 INNER JOIN functionality
     ON functionality.id = push_info.functionality
 WHERE
   node.iri = "node1" AND
   functionality.name = "functionality1";

Answer 1

标准化你有一张桌子。在您开始“规范化”或开始谈论“规范化”之前，请了解什么是规范化。这是关键问题：您能否用较小的表替换此表，以便它们始终加入其中？为此，在给定的应用程序情况下，必须可以将行在表中的标准表述为一个或多个 AND 的“... AND ...”。如果可以，标准化可能会建议进行替换。如果你不能，它就不会。 （基数通常不允许我们确定。）

更多的表只有你才能知道是否要存储这张表不能告诉你的信息，以便你需要更多的表。例如，如果您想记录一个特定节点存在，即使它不参与该表所代表的应用关系，那么您需要另一个表。

关系型 vs 非关系型关系型数据库允许通用声明查询和完整性实施，但有一定的实施成本（以及一些自动优化）。其他数据结构都支持专门且主要是非声明性的查询和完整性执行，实现成本有所提高，但其他情况通常很尴尬和/或昂贵。您必须了解您的使用模式以及成本和收益如何在这些众多维度之间进行权衡，以便确定哪种设计是“最好的”。我们总是可以合理地从关系设计开始，然后在必要和期望的地方进行专门化。