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 записей?
• Должен ли я использовать нормализованный способ организации таблиц, то есть один для узлов, другой для функций, другой для адресов и использования JOIN в SELECT? Затем, как я могу автоматически удалить записи из таблиц, которые больше не связаны, то есть узел, который не имеет функциональности и не имеет конечной точки?
• Должен ли я использовать, например, простой движок базы данных, такой как Redis, установив ключи для функциональности узла (строка и значение список адресов) и другой набор ключей для конечных точек (хэш)?

Я хотел бы добавить, что я буду использовать Java для обработки доступа к данным.

Спасибо вам за помощь. Я был бы очень признателен и посоветовал бы, как лучше всего это сделать.

Edit: опция для выбора с несколькими простыми таблицами (я думаю, что все в порядке)

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

Нормализация У вас есть таблица. Перед тем, как начать «нормализацию» или начать говорить о «нормализации», узнать, какая нормализация is. Вот главный вопрос: можете ли вы заменить эту таблицу на меньшие, чтобы они всегда к ней присоединялись? Чтобы это было так, можно было бы рассказать критерий для строки в таблице в данной ситуации приложения как «... И ...» для одного или нескольких И. Если вы можете, нормализация может предложить сделать эту замену. Если вы этого не сделаете, это не произойдет. (Значения в основном не позволяют нам это определить.)

Другие таблицы Только вы можете узнать, хотите ли вы хранить информацию, которую эта таблица не может вам рассказать, так что вам нужно больше таблиц. Например, если вы хотите записать, что определенный узел существует, хотя он не участвует в отношении приложения, представленном этой таблицей, вам нужна другая таблица.

Relational против не реляционных баз данных позволяют общих декларативные запросов и целостности органов, с определенными издержками реализации (и некоторой автоматической оптимизацией). Другие структуры данных каждая поддержка специализированная & в значительной степени не декларативная проверка запросов и целостности с улучшенными затратами на внедрение, но с другие случаи, как правило, неудобные и/или дорогие. Вы должны знать свои шаблоны использования и как издержки и выгоды распределяются между этими многими измерениями, чтобы определить, какой дизайн «наилучший». Мы всегда можем разумно начать с реляционного дизайна, а затем специализироваться там, где это необходимо и желательно.