Quelle est la différence entre une base de données relationnelle et non relationnelle?
Je sais que des solutions telles que MySQL, PostgreSQL et MS SQL Server sont des systèmes de bases de données relationnelles, et NoSQL, MongoDB, etc., sont des SGBD non relationnels.
Cependant, quelles sont les différences entre les deux types de système?
Les termes de Layman sont préférables.
Merci.
Les bases de données relationnelles ont une base mathématique (théorie des ensembles, théorie relationnelle), qui sont distillées en SQL == Langage d'interrogation structuré.
Les nombreuses formes de NoSQL (par exemple, magasin de clé-valeur, etc. basé sur des documents, des graphes, des objets, etc.) peuvent être basées ou non sur une seule théorie mathématique sous-jacente. Comme S. Lott l’a bien fait remarquer, les magasins de données hiérarchiques ont effectivement une base mathématique. La même chose pourrait être dite pour bases de données de graphes .
Je ne connais pas de langage de requête universel pour les bases de données NoSQL.
Hmm, je ne sais pas trop quelle est votre question.
Dans le titre, vous posez des questions sur les bases de données (DB), tandis que dans le corps de votre texte, vous posez des questions sur les systèmes de gestion de bases de données (SGBD). Les deux sont complètement différents et exigent des réponses différentes.
Un SGBD est un outil qui vous permet d'accéder à une base de données.
Outre les données elles-mêmes, une base de données est le concept de la structure de ces données.
Vous pouvez donc configurer une base de données relationnelle sans SGBDR ou utiliser un SGBDR pour stocker des données non relationnelles, tout comme vous pouvez programmer avec la méthodologie Oriented Object avec un compilateur non alimenté par OO, ou inversement.
Je vais me concentrer sur la signification de la base de données relationnelle (RDB) et laisser la discussion sur ce que les systèmes font aux autres.
Une base de données relationnelle (le concept) est une structure de données qui vous permet de lier des informations provenant de différents "tableaux" ou de différents types de compartiments de données. Un compartiment de données doit contenir ce qu'on appelle une clé ou un index (qui permet d'identifier de manière unique tout bloc de données atomique dans le compartiment). D'autres compartiments de données peuvent faire référence à cette clé afin de créer un lien entre leurs atomes de données et le atom pointé par la clé).
Une base de données non relationnelle stocke simplement des données sans mécanismes explicites et structurés pour lier les données de différents compartiments les unes aux autres.
En ce qui concerne la mise en œuvre d'un tel schéma, si vous avez un fichier papier avec un index et dans un fichier papier différent, vous vous référez à l'index pour obtenir les informations pertinentes, vous avez alors implémenté une base de données relationnelle, même si elle est assez simple. Vous voyez donc que vous n’avez même pas besoin d’un ordinateur (bien sûr, cela peut devenir fastidieux très rapidement sans aide), de la même manière, vous n’avez pas besoin d’un SGBDR, bien qu’on puisse dire qu’un SGBDR est le bon outil pour le poste. Cela dit, il existe des variations quant à ce que les différents outils peuvent faire, alors choisir le bon outil pour le travail peut ne pas être aussi simple.
J'espère que ce sont des termes simples et utiles à votre compréhension.
La plupart de ce que vous "savez" est faux.
Tout d’abord, comme le signalent quelques gourous des relations de manière routinière (et parfois déconcertante), SQL ne correspond pas aussi étroitement à la théorie relationnelle que beaucoup de gens le pensent. Deuxièmement, la plupart des différences entre les éléments "NoSQL" ont relativement peu à voir avec le caractère relationnel ou non. Enfin, il est assez difficile de dire en quoi "NoSQL" diffère de SQL car les deux représentent un assez large éventail de possibilités.
La principale différence sur laquelle vous pouvez compter est que presque tout ce qui prend en charge SQL prend en charge des éléments tels que les déclencheurs dans la base de données elle-même, c’est-à-dire que vous pouvez définir des règles dans la base de données proprement dite, destinées à garantir la cohérence interne des données. Par exemple, vous pouvez configurer les éléments de sorte que votre base de données affirme qu'une personne doit avoir une adresse. Si vous le faites, chaque fois que vous ajoutez une personne, vous serez obligé d'associer cette personne à une adresse. Vous pouvez ajouter une nouvelle adresse ou l'associer à une adresse existante, mais d'une manière ou d'une autre, la personne doit avoir une adresse. De même, si vous supprimez une adresse, vous serez obligé de supprimer toutes les personnes se trouvant actuellement à cette adresse ou de les associer à une autre adresse. Vous pouvez faire la même chose pour d'autres relations, par exemple en disant que chaque personne doit avoir une mère, chaque bureau doit avoir un numéro de téléphone, etc.
Notez que ce genre de choses est également garanti que cela se produira de manière atomique, donc si quelqu'un regarde la base de données au fur et à mesure que vous ajoutez la personne, soit il ne la verra pas du tout, soit il la verra avec l'adresse (ou la mère, etc.)
La plupart des bases de données NoSQL ne n'essayent pas de fournir ce type d'application dans la base de données proprement dite. C'est à vous, dans le code qui utilise la base de données, d'appliquer les relations nécessaires à vos données. Dans la plupart des cas, il est également possible de voir des données qui ne sont que partiellement correctes. Ainsi, même si vous avez un arbre généalogique dans lequel chaque personne est supposée être associée à des parents, il peut arriver que les contraintes que vous avez imposées ne soient pas réellement contraignantes. forcée. Certains vous laisseront le faire à volonté. D'autres garantissent que cela ne se produit que temporairement, bien que le temps exact qu'il puisse/puisse durer puisse être remis en question.
La base de données relationnelle utilise un système formel de prédicats pour traiter les données. L'implémentation physique sous-jacente n'a aucune substance et peut varier pour optimiser certaines opérations, mais elle doit toujours assumer le modèle relationnel . En termes simples, cela signifie simplement Je sais exactement combien de valeurs (attributs) chaque rangée (Tuple) dans mon tableau (relation) a et maintenant je veux exploiter le fait en conséquence, complètement et à l'extrême. C'est la vraie nature de la bête.
Puisque nous sommes évidemment la génération qui a eu une éducation relationnelle, si vous regardez les modèles de base de données NoSQL du point de vue du modèle relationnel, toujours en termes simples, la première différence évidente est qu'aucune hypothèse sur le nombre de valeurs qu'une ligne ne peut contenir est jamais fait. Ceci simplifie excessivement la question et ne s’applique pas proprement aux complexités des modèles physiques de chaque base de données NoSQL, mais c’est le summum du modèle relationnel et la première hypothèse que nous devons laisser de côté ou, si vous préférez, le plus important. saut que nous devons faire.
Nous pouvons convenir de deux choses qui sont vraies pour chaque SGBD: il peut stocker n'importe quel type de données et dispose d'assez de bases mathématiques pour permettre de gérer les données de toutes les manières imaginables. La réalité est que vous ne voudrez jamais commettre l’erreur de mettre l’un des deux points à l’épreuve, mais plutôt de vous en tenir à ce pour quoi le SGBD a été conçu. En termes simples: respecte la bête en elle!
(Veuillez noter que j'ai évité de comparer les normes (bien évidemment) bien fondées concernant le modèle relationnel aux nombreuses versions fournies par les bases de données NoSQL. Si vous le souhaitez, considérez les bases de données NoSQL comme un terme générique pour tout SGBD. cela ne suppose pas complètement le modèle relationnel, à l’exclusion de tout le reste. Les différences sont trop nombreuses, mais c’est la différence principale et celle qui, à mon avis, vous aiderait le plus à comprendre les deux.)
Essayez d’expliquer cette question dans un niveau faisant référence à un peu de technologie
Prenez MongoDB et SQL traditionnel à des fins de comparaison, imaginez le scénario de la publication d'un tweet sur Twitter. Ce Tweet contient 9 images. Comment stockez-vous ce Tweet et ses images correspondantes?
En termes de relation SQL traditionnelle, vous pouvez stocker les tweets et les images dans des tables distinctes et représenter la connexion en créant une nouvelle table.
De plus, vous pouvez définir un champ de type image, compresser les 9 images dans un document binaire et les stocker dans ce champ.
En utilisant MongoDB, vous pouvez construire un document comme celui-ci (similaire au concept de table en SQL relationnel):
{
"id":"XXX",
"user":"XXX",
"date":"xxxx-xx-xx",
"content":{
"text":"XXXX",
"picture":["p1.png","p2.png","p3.png"]
}
Par conséquent, à mon avis, la principale différence concerne la manière dont vous stockez les données et le niveau de stockage des relations entre elles.
Dans cet exemple, les données sont le Tweet et les images. Les différents mécanismes concernant le niveau de relation de stockage entre eux jouent également un rôle important dans la différence entre les deux.
J'espère que ce petit exemple permet de montrer la différence entre SQL et NoSQL (ACID et BASE).
Voici un lien d'image sur les objectifs de NoSQL à partir d'Internet:
La différence entre relationnel et non relationnel est exactement cela. L'architecture de base de données relationnelle fournit des contraintes telles que des clés primaires, des clés étrangères, etc. permettant de lier deux ou plusieurs tables dans une relation. C’est une bonne chose de normaliser nos tables, c’est-à-dire de scinder les informations sur ce que la base de données représente en plusieurs tables différentes, ce qui permet de conserver l’intégrité des données.
Par exemple, supposons que vous disposiez d’une série de tableaux contenant des informations sur un employé. Vous ne pouvez pas supprimer un enregistrement d'une table sans supprimer tous les enregistrements associés à cet enregistrement des autres tables. De cette façon, vous implémentez l'intégrité des données. La base de données non relationnelle ne fournit pas cette construction de contraintes qui vous permettra d'implémenter l'intégrité des données.
Sauf si vous n'implémentez pas cette contrainte dans l'application frontale utilisée pour remplir les tables des bases de données, vous implémentez un désordre qui peut être comparé à l'état sauvage.
En termes simples, il est fortement structuré ou non structuré, ce qui implique que vous avez différents degrés d'adaptabilité pour votre base de données. Des différences apparaissent dans l'indexation, notamment parce que vous devez vous assurer qu'un certain index de référence peut être lié à un autre élément -> ceci est une relation. La structure plus stricte de la base de données relationnelle découle de cette exigence.
À noter que NosDB fournit apaprently des bases de données relationnelles et non relationnelles ainsi qu'un moyen d'interroger les deux http://www.alachisoft.com/nosdb/sql-cheat-sheet.html