Comment convertir une base de données relationnelle existante en magasin de valeurs-clés?

Question

J'essaie de mapper une base de données relationnelle existante à un magasin de valeurs clés. Quelques exemples de tables sont représentés ci-dessous.

Pour un exemple du tableau ci-dessus « Détails de l'employé » peut être représentée comme suit Redis (ou tout autre magasin similaire clé-valeur)

set emp_details.first_name.01 "John" 
set emp_details.last_name.01 "Newman" 
set emp_details.address.01 "New York" 

set emp_details.first_name.02 "Michael" 
set emp_details.last_name.02 "Clarke" 
set emp_details.address.02 "Melbourne" 

set emp_details.first_name.03 "Steve" 
set emp_details.last_name.03 "Smith" 
set emp_details.address.03 "Los Angeles" 

Le tableau « Paiements » peut aussi être représenté comme ci-dessus. Mais cette méthode ne construit pas la relation un-à-plusieurs entre la table "Employee Details" et la table "Payments". Par conséquent, existe-t-il une meilleure façon d'implémenter un magasin de valeurs-clés à partir d'un SGBDR existant. Vous pouvez vous référer à ces deux tables et suggérer un meilleur schéma de clé pour stocker les valeurs. Merci d'avance.

Answer 1

Les bases de données Nosql sont essentiellement des magasins agrégés. Les relations et les valeurs associées sont stockées dans une partie «valeur» de la conception key-val. Éviter les jointures améliore les performances.

Excellente Llink sur la modélisation NoSQL - https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/

Answer 2

Relational tables represent business/application relationships/associations. (FKs clés étrangères) se appelé relations, mais ne sont pas. (Elles ne sont que des vérités à propos de chaque situation métier/application & état de la base de données correspondante.) Une déclaration de contrainte FK indique simplement au SGBDR que les sous-chaînes apparaissent ailleurs comme une super-clé (clé unique). (Bien que le SGBD puisse l'utiliser pour optimiser.) Les contraintes ne sont pas nécessaires pour interroger les relations.

Les FK sont relationnels. Dans un SGBD non relationnel si vous voulez certaines requêtes plus simples ou plus rapides, par exemple quand ils sont les équivalents de certaines jointures relationnelles impliquant certains FK, au détriment de compliquer les mises à jour & autres requêtes, alors vous faites des choses comme enregistrer des données de manière redondante, imbriquée/hiérarchique ou utiliser des pointeurs/indirection.

Cette différence relationnelle vs schémas non relationnelles & interrogation est fondamentale pour la difference dans les modèles de données & aux avantages du modèle relationnel. L'utilisation de tables relationnelles en tant que structure de données permet une interrogation sans application directe, avec certaines possibilités d'optimisation en matière de complexité d'implémentation. Toute intro à un SGBD NoSQL particulier expliquera comment modéliser la requête &. (En général, en supposant un relationnel de conception initiale.)