Redis vs MySQL用于简单数据库

时间:2016-11-09 14:16:16

标签: mysql redis database-normalization

我想创建一个简单的数据库,必须存储节点,它们的功能和地址,以便在出现问题时通知。最初我在考虑使用一个简单的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";

1 个答案:

答案 0 :(得分:0)

规范化您有一张桌子。在开始“规范化”或开始谈论关于“规范化”之前,找出规范化。以下是关键问题:您可以用较小的表替换此表,以便它们始终加入它吗?为此,必须可以将给定应用情况下表中行的标准短语称为“...... AND ...”以表示一个或多个AND。如果可以,标准化可能会建议进行替换。如果你不能,它就不会。 (基数通常不允许我们确定。)

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

关系与非关系数据库允许通用声明性查询和完整性实施,具有某些实施成本(以及一些自动优化)。其他数据结构均支持专用&主要是非声明性的查询和完整性执行,实施成本提高,但其他案例通常很难和/或昂贵。您必须了解您的使用模式以及成本和收益如何在这些维度之间进行权衡,以确定哪种设计“最佳”。我们总是可以合理地从关系设计开始,然后专注于必要和可取的地方。