mysql - 用于简单数据库的 Redis 与 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

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

更多表格 只有您自己知道是否要存储此表格无法告诉您的信息，以便您需要更多表格。例如，如果您想要记录某个特定节点存在，即使它不参与此表所表示的应用程序关系，那么您需要另一个表。

关系型与非关系型 关系型数据库允许通用声明查询和完整性实现，具有一定的实现成本(和一些自动优化)。其他数据结构均支持专门且主要是非声明性的查询和完整性实现，具有改进的实现成本，但其他情况通常很尴尬和/或昂贵。您必须了解您的使用模式以及成本和 yield 如何在这些许多维度之间进行权衡，才能决定哪种设计是“最佳”。我们总是可以合理地从关系设计开始，然后在必要和可取的地方进行专门设计。