Redis vs MySQL für einfache Datenbank

Question

Ich möchte eine einfache Datenbank erstellen, die Knoten, ihre Funktionalitäten und Adresse speichern müssen, um im Falle von Problemen zu benachrichtigen. Anfangs dachte ich auf eine einfache SQL-Datenbank:

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

wo Knoten und Funktionalitäten können viele Adresse, N auf N. Auf diese Weise, die Adresse zu bekommen Ich werde diese beiden Sätze nur ausführen:

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

jedoch nach ein wenig zu lesen, habe ich mehrere Zweifel an:

• Ist das für eine Datenbank ok, die zunächst nicht mehr als 10000 Einträge haben?
• Sollte ich die Normalisierung der Tabellenorganisation verwenden, dh eine für Knoten, eine andere für Funktionalitäten und eine andere für Adressen und die Verwendung von JOIN in SELECT? Wie könnte ich dann automatisch die Einträge aus den Tabellen löschen, die nicht mehr verknüpft sind, dh ein Knoten, der keine Funktionalität und keinen Endpunkt hat?
• Sollte ich zum Beispiel eine einfache Datenbank-Engine wie Redis verwenden, Schlüssel auf Node-Funktionalität (String und Wert eine Liste von Adressen) und einen anderen Satz von Schlüsseln zu den Endpunkten (Hash)?

Ich möchte hinzufügen, dass ich Java verwenden werde, um den Zugriff auf Daten zu behandeln.

Danke für Ihre Hilfe. Ich würde wirklich schätzen und beraten, was der beste Weg ist, um solche Dinge zu tun.

Edit: Option für ausgewählte mit mehreren einfachen Tabellen (ich glaube, OK ist)

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

Normalisierungs Sie einen Tisch haben. Bevor Sie "Normalisieren" beginnen oder über über "Normalisieren" starten, finden Sie heraus, welche Normalisierung ist. Hier ist die Schlüsselfrage: Können Sie diese Tabelle durch kleinere ersetzen, damit sie sich immer daran anschließen? Dazu muss es möglich sein, das Kriterium für eine Zeile in einer gegebenen Anwendungssituation als "... AND ..." für eine oder mehrere ANDs zu formulieren. Wenn Sie können, kann die Normalisierung vorschlagen, diesen Ersatz zu tun. Wenn Sie nicht können, wird es nicht. (Kardinalitäten ermöglichen es uns im Allgemeinen nicht, das zu bestimmen.)

Weitere Tabellen Nur Sie können wissen, ob Sie Informationen speichern möchten, die diese Tabelle Ihnen nicht mitteilen kann, so dass Sie mehr Tabellen benötigen. Wenn Sie beispielsweise notieren möchten, dass ein bestimmter Knoten existiert, obwohl er nicht an der Anwendungsbeziehung teilnimmt, die diese Tabelle darstellt, benötigen Sie eine andere Tabelle.

Relational vs nicht Relationale Datenbanken erlaubt generic deklarative Abfrage- und Integrität Durchsetzung, mit bestimmt Implementierungskosten (und einiger automatisierten Optimierung). Andere Datenstrukturen unterstützen jeweils spezialisierte & weitestgehend nicht-deklarative Abfrage und Integrität Durchsetzung, mit verbesserten Implementierungskosten, aber mit anderen Fälle in der Regel peinlich und/oder teuer. Sie müssen Ihre Nutzungsmuster kennen und wie Kosten und Nutzen unter diesen vielen Dimensionen abgewogen werden, um zu entscheiden, welches Design "das Beste" ist. Wir können immer vernünftig mit einem relationalen Design beginnen, dann spezialisieren, wo notwendig und wünschenswert gezeigt.