SQL VS NOSQL: Comment choisir

Les plats clés

• Les bases de données SQL sont idéales pour les projets avec des exigences de données connexes bien définies et lorsque l'intégrité des données est critique. Ils sont souvent utilisés pour les magasins en ligne et les systèmes bancaires. Les bases de données NoSQL sont mieux adaptées aux projets avec des exigences de données non apparentées, évolutives ou indéterminées, où la vitesse et l'évolutivité sont essentielles. Ils sont couramment utilisés pour les réseaux sociaux, la gestion des clients et les systèmes d'analyse Web.
• Les bases de données NoSQL offrent une flexibilité dans le stockage de données, permettant l'addition ou la suppression des champs à volonté. Ils stockent toutes les données sur un individu dans un seul document, simplifiant la recherche de données et la recherche en texte intégral. Cependant, ils n'implémentent pas les règles d'intégrité des données ou ne prennent pas en charge les transactions sur plusieurs documents.
• Les bases de données SQL sont nécessaires pour les projets nécessitant une intégrité robuste des données et un support de transaction, comme un système de gestion d'entrepôt. Ils stockent des données connexes dans les tableaux, nécessitent un schéma avant l'utilisation et les jointures de table de support. Cependant, le schéma est rigide et les données peuvent devenir fragmentées, ce qui le rend difficile pour les développeurs ou les administrateurs système pour examiner la base de données.

Dans l'article précédent, nous avons discuté des principales différences entre les bases de données SQL et NOSQL. Dans ce suivi, nous appliquerons nos connaissances à des scénarios spécifiques et déterminerons la meilleure option. Pour récapituler: Bases de données SQL:

• stocker des données liées dans les tableaux
• nécessitent un schéma qui définit les tables avant d'utiliser
• Encourager la normalisation pour réduire la redondance des données
• La table de support rejoint pour récupérer les données connexes à partir de plusieurs tables dans une seule commande
• Implémentez les règles d'intégrité des données
• Fournir des transactions pour garantir que deux ou plusieurs mises à jour réussissent ou échouent en tant qu'unité atomique
• peut être mis à l'échelle (avec un certain effort)
• Utilisez un langage déclaratif puissant pour interroger
• offrir beaucoup de soutien, d'expertise et d'outils.

Bases de données NoSQL:

• Stocker les données liées dans des documents de valeur de nom de JSON
• peut stocker des données sans spécifier un schéma
• doit généralement être dénormalisé de sorte que les informations sur un élément sont contenues dans un seul document
• ne doit pas exiger des jointures (des documents dénormalisés présumés sont utilisés)
• permettre que les données soient enregistrées n'importe où à tout moment sans vérification
• Garantir les mises à jour d'un seul document - mais pas plusieurs documents
• Fournir d'excellentes performances et évolutivité
• Utilisez des objets de données JSON pour interroger
• sont une technologie plus récente et passionnante.

Les bases de données SQL sont idéales pour les projets où les exigences peuvent être déterminées et que l'intégrité des données robuste est essentielle. Les bases de données NoSQL sont idéales pour les exigences de données non liées, indéterminées ou en évolution où la vitesse et l'évolutivité sont plus importantes. En termes plus simples:

• SQL est numérique. Il fonctionne mieux pour des éléments discrets clairement définis avec des spécifications exactes. Les cas d'utilisation typiques sont les magasins en ligne et les systèmes bancaires.
• NOSQL est analogique. Il fonctionne mieux pour les données organiques avec les exigences fluides. Les cas d'utilisation typiques sont les réseaux sociaux, la gestion des clients et les systèmes d'analyse Web.

Peu de projets seront exactement un ajustement. L'une ou l'autre option pourrait être viable si vous avez des données moins profondes ou naturellement dénormalisées. Mais soyez conscient de ces exemples de scénarios simplifiés avec des généralisations radicales! Vous en savez plus sur votre projet que moi, et je ne recommanderais pas de passer de SQL à Nosql ou vice versa, sauf s'il offre des avantages considérables. C’est votre choix. Considérez les avantages et les inconvénients au début de votre projet et vous ne pouvez pas vous tromper.

Scénario un: une liste de contacts

Revenons la roue et mettons en œuvre un système de carnet d'adresses basé sur SQL. Notre tableau de contact naïf initial est défini avec les champs suivants:

• id
• Titre
• FirstName
• LastName
• Sexe
• Téléphone
• Email
• Adresse1
• Adresse2
• Adresse3
• ville
• région
• Zipcode
• pays

Problème ONE: Peu de personnes ont un seul numéro de téléphone. Nous en avons probablement besoin au moins trois pour la ligne terrestre, le mobile et le lieu de travail, mais peu importe combien nous allouons - quelqu'un, quelque part en voudra plus. Créons une table téléphonique séparée afin que les contacts puissent en avoir autant qu'ils le souhaitent. Cela normalise également nos données - nous n'avons pas besoin d'un NULL pour les contacts sans nombre:

• contact_id
• nom (texte tel que la ligne terrestre, le mobile de travail, etc.)
• numéro

Problème deux: Nous avons le même problème avec les adresses e-mail, alors créons un tableau de messagerie similaire:

• contact_id
• nom (texte tel que e-mail à domicile, e-mail de travail, etc.)
• Adresse

Problème trois: Nous ne voulons peut-être pas saisir une adresse (géographique), ou nous pouvons vouloir saisir plusieurs adresses pour le travail, la maison, les maisons de vacances, etc. Nous avons donc besoin d'un nouveau tableau d'adresse:

• contact_id
• nom (texte tel que la maison, le bureau, etc.)
• Adresse1
• Adresse2
• Adresse3
• ville
• région
• Zipcode
• pays

Notre table de contact d'origine a été réduite à:

• id
• Titre
• FirstName
• LastName
• Sexe

Super - Nous avons une base de données normalisée qui peut stocker n'importe quel nombre de numéros de téléphone, d'adresses e-mail et d'adresses pour tout contact. Malheureusement … Le schéma est rigide Nous n'avons pas examiné le ou les prénom du contact, la date de naissance, l'entreprise ou le rôle de poste. Peu importe le nombre de champs que nous ajoutons, nous recevrons bientôt des demandes de mise à jour de notes, d'anniversaires, de statuts de relation, de comptes de médias sociaux, de mesures de jambe intérieure, de type de fromage préféré, etc. Il est impossible de prévoir toutes les options, donc nous ' d éventuellement créer une table autre chose avec des paires de valeurs de nom pour faire face. Les données sont fragmentées Il n'est pas facile pour les développeurs ou les administrateurs système d'examiner la base de données. La logique du programme deviendra également plus lente et plus complexe, car il n'est pas pratique de récupérer les données d'un contact dans une seule instruction sélectionnée avec plusieurs clauses de jointure. (vous pourriez, mais le résultat contiendrait chaque combinaison de téléphone, de courriel et d'adresse: si quelqu'un avait trois numéros de téléphone, cinq e-mails et deux adresses, la requête SQL générerait trente résultats.) Enfin, la recherche en texte intégral est difficile. Si quelqu'un entre dans la chaîne "SitePoint" , nous devons vérifier les quatre tables pour voir si cela fait partie d'un nom de contact, d'un téléphone, d'un e-mail ou d'une adresse et classer le résultat en conséquence. Si vous avez déjà utilisé la recherche de WordPress, vous comprendrez à quel point cela peut être frustrant.

l'alternative nosql

Nos données de contact concernent les gens. Ils sont imprévisibles et ont des exigences différentes à des moments différents. La liste de contacts bénéficierait de l'utilisation d'une base de données NoSQL, qui stocke toutes les données sur un individu dans un seul document dans la collecte de contacts:

<span>{
</span>  <span>name: [
</span>    <span>"Billy", "Bob", "Jones"
</span>  <span>],
</span>  <span>company: "Fake Goods Corp",
</span>  <span>jobtitle: "Vice President of Data Management",
</span>  <span>telephone: {
</span>    <span>home: "0123456789",
</span>    <span>mobile: "9876543210",
</span>    <span>work: "2244668800"
</span>  <span>},
</span>  <span>email: {
</span>    <span>personal: "bob@myhomeemail.net",
</span>    <span>work: "bob@myworkemail.com"
</span>  <span>},
</span>  <span>address: {
</span>    <span>home: {
</span>      <span>line1: "10 Non-Existent Street",
</span>      <span>city: "Nowhere",
</span>      <span>country: "Australia"
</span>    <span>}
</span>  <span>},
</span>  <span>birthdate: <span>ISODate</span>("1980-01-01T00:00:00.000Z"),
</span>  <span>twitter: '@bobsfakeaccount',
</span>  <span>note: "Don't trust this guy",
</span>  <span>weight: "200lb",
</span>  <span>photo: "52e86ad749e0b817d25c8892.jpg"
</span><span>}</span>

Dans cet exemple, nous n'avons pas stocké le titre ou le sexe du contact, et nous avons ajouté des données qui n'ont besoin de s'appliquer à personne d'autre. Cela n'a pas d'importance - notre base de données NoSQL ne se soucie pas, et nous pouvons ajouter ou supprimer les champs à volonté. Étant donné que les données du contact sont contenues dans un seul document, nous pouvons récupérer certaines ou toutes les informations à l'aide d'une seule requête. Une recherche en texte intégral est également plus simple; Dans MongoDB, nous pouvons définir un index sur tous les contacts champs de texte en utilisant:

db<span>.contact.createIndex({ "$**": "text" });</span>

Effectuez ensuite une recherche en texte intégral en utilisant:

db<span>.contact.find({
</span>  <span>$text: { $search: "something" }
</span><span>});</span>

Scénario deux: un réseau social

Un réseau social peut utiliser des magasins de données de contact similaires, mais il développe l'ensemble de fonctionnalités avec des options telles que les liens de relation, les mises à jour de statut, la messagerie et les «goûts». Ces installations peuvent être mises en œuvre et abandonnées en réponse à la demande des utilisateurs - il est impossible de prédire comment ils évolueront. En outre:

• La plupart des mises à jour de données ont un seul point d'origine: l'utilisateur. Il est peu probable que nous devions mettre à jour deux enregistrements ou plus à un moment donné, de sorte que les fonctionnalités de type transaction ne sont pas nécessaires.
• Malgré ce que certains utilisateurs peuvent penser, il est peu probable qu'une mise à jour de statut échouée entraîne une effondrement mondial ou une perte financière. L'interface et les performances de l'application ont une priorité plus élevée que l'intégrité des données robuste.

NoSQL semble être un bon ajustement. La base de données nous permet d'implémenter rapidement les fonctionnalités stockant différents types de données. Par exemple, toutes les mises à jour du statut datées de l'utilisateur peuvent être placées dans un seul document dans la collection d'état:

<span>{
</span>  <span>name: [
</span>    <span>"Billy", "Bob", "Jones"
</span>  <span>],
</span>  <span>company: "Fake Goods Corp",
</span>  <span>jobtitle: "Vice President of Data Management",
</span>  <span>telephone: {
</span>    <span>home: "0123456789",
</span>    <span>mobile: "9876543210",
</span>    <span>work: "2244668800"
</span>  <span>},
</span>  <span>email: {
</span>    <span>personal: "bob@myhomeemail.net",
</span>    <span>work: "bob@myworkemail.com"
</span>  <span>},
</span>  <span>address: {
</span>    <span>home: {
</span>      <span>line1: "10 Non-Existent Street",
</span>      <span>city: "Nowhere",
</span>      <span>country: "Australia"
</span>    <span>}
</span>  <span>},
</span>  <span>birthdate: <span>ISODate</span>("1980-01-01T00:00:00.000Z"),
</span>  <span>twitter: '@bobsfakeaccount',
</span>  <span>note: "Don't trust this guy",
</span>  <span>weight: "200lb",
</span>  <span>photo: "52e86ad749e0b817d25c8892.jpg"
</span><span>}</span>

Bien que ce document puisse devenir long, nous pouvons récupérer un sous-ensemble du tableau, comme la mise à jour la plus récente. L'historique de statut complet de chaque utilisateur peut également être recherché rapidement. Maintenant, nous voulions introduire un choix d'émoticône lors de la publication d'une mise à jour. Ce serait une question d'ajouter une référence graphique aux nouvelles entrées dans le tableau de mise à jour. Contrairement à une boutique SQL, il n'est pas nécessaire de définir des émoticônes de message précédent sur NULL - notre logique de programme peut afficher une image par défaut ou aucune image si une émoticône n'est pas définie.

Scénario trois: un système de gestion de l'entrepôt

Considérez un système qui surveille les marchandises entreposées. Nous devons enregistrer:

• Produits arrivant à l'entrepôt et alloués à un emplacement spécifique / baie
• Mouvements de marchandises dans l'entrepôt, par ex. Réorganisation du stock afin que les mêmes produits soient dans les emplacements adjacents
• Les commandes et la suppression ultérieure des produits de l'entrepôt pour la livraison.

Nos exigences de données:

1. Les informations génériques du produit telles que les quantités de boîte, les dimensions et la couleur peuvent être stockées, mais ce sont des données discrètes que nous pouvons identifier et appliquer à tout. Il est peu probable que nous nous préoccupons des détails, tels que la vitesse du processeur d'ordinateur portable ou la durée de vie de la batterie du smartphone estimé.
2. Il est impératif de minimiser les erreurs. Nous ne pouvons pas faire disparaître des produits ou être déplacés vers un endroit où différents produits sont déjà stockés.
3. Dans sa forme la plus simple, nous enregistrons le transfert d'articles d'une zone physique à une autre - ou en retirant de l'emplacement A et en plaçant dans l'emplacement B. Il s'agit de deux mises à jour pour la même action.

Nous avons besoin d'un magasin robuste avec l'intégrité des données et la prise en charge des transactions forcées. Seule une base de données SQL satisfera (actuellement) à ces exigences.

Exposez-vous!

J'espère que ces scénarios vous aideront, mais chaque projet est différent et, en fin de compte, vous devez prendre votre propre décision. (bien que nous, les développeurs, sommes aptes à justifier nos choix technologiques, quelle que soit leur qualité!) Le meilleur conseil: exposez-vous à autant de technologies que possible. Cette connaissance vous permettra de porter un jugement raisonné et émotionnellement impartial concernant SQL ou Nosql. Bonne chance.

Questions fréquemment posées (FAQ) sur SQL vs NoSQL

Quelles sont les principales différences entre les bases de données SQL et NOSQL?

Les bases de données SQL et NOSQL diffèrent de plusieurs manières. Les bases de données SQL sont relationnelles, ce qui signifie qu'elles organisent des données dans les tableaux et les lignes. Ils utilisent le langage de requête structuré (SQL) pour définir et manipuler les données. D'un autre côté, les bases de données NoSQL sont non relationnelles et peuvent stocker les données de plusieurs manières: des paires basées sur des documents, basées sur des colonnes, basées sur des graphiques ou des clés. Ils sont particulièrement utiles pour travailler avec de grands ensembles de données distribuées.

Quand dois-je utiliser SQL sur Nosql?

Les bases de données SQL sont un bon choix lorsque vous avez un schéma clair et que l'intégrité des données est de la plus haute importance. Ils sont également bénéfiques lorsque vous devez effectuer des requêtes complexes. Les bases de données SQL sont conformes à l'acide garantissant des transactions fiables.

Quand le NOSQL est un meilleur choix que SQL?

Les bases de données NoSQL sont un meilleur choix lorsque vous avez besoin de stocker de grands volumes de données ou lorsque la structure des données n'est pas clair ou change avec le temps. Ils offrent une flexibilité, une évolutivité et une vitesse, ce qui en fait un bon choix pour les applications en temps réel et les mégadonnées.

SQL et NOSQL peuvent-ils coexister dans le même projet?

Oui, SQL et NOSQL peut coexister dans le même projet. Ceci est connu comme une architecture de persistance polyglot. Le choix de la base de données dépend des exigences spécifiques de chaque partie de votre application.

Quelles sont les bases de données SQL et NOSQL populaires?

Les bases de données SQL populaires incluent MySQL, Oracle et PostgreSQL. Les bases de données NOSQL populaires incluent MongoDB, Cassandra et Redis.

En quoi la modélisation des données diffère-t-elle entre SQL et Nosql?

Dans les bases de données SQL, les données sont généralement modélisées à l'aide d'une approche structurée basée sur un schéma avec un schéma avec un schéma structuré avec une approche de schéma structurée avec un schéma avec un schéma structuré avec un schéma avec un schéma structuré avec une approche de schéma avec un schéma structuré avec un schéma avec un schéma structuré avec une approche de schéma avec un schéma structuré avec un schéma avec une approche structurée avec un schéma avec un schéma avec une approche structurée avec des schéma tableaux et relations. Dans les bases de données NOSQL, la modélisation des données peut être effectuée de différentes manières en fonction du type de base de données NOSQL: document, valeur clé, colonne ou graphique.

Comment l'évolutivité du manche SQL et NOSQL?

Les bases de données SQL évoluent généralement verticalement en ajoutant du matériel plus puissant, tandis que les bases de données NOSQL évoluent horizontalement en ajoutant plus de serveurs à gérer plus de trafic.

Qu'est-ce que le théorème CAP et comment s'applique-t-il à SQL et Nosql?

Le théorème CAP indique qu'il est impossible qu'un magasin de données distribué fournisse simultanément plus de deux des trois garanties suivantes: cohérence, disponibilité et tolérance de partition. Les bases de données SQL hiérartissent la cohérence et la disponibilité, tandis que les bases de données NOSQL hiérartissent la disponibilité et la tolérance de partition.

Comment les transactions SQL et NOSQL gèrent-elles?

Les bases de données SQL utilisent-elles les propriétés acides (atomicité, cohérence, isolement, durée) pour les transactions. Les bases de données NoSQL, en revanche, ne fournissent généralement pas toutes les propriétés acides. Au lieu de cela, ils se concentrent sur le modèle de base (essentiellement disponible, à l'état souple, éventuellement cohérent).

Quels sont certains cas d'utilisation pour SQL et NOSQL?

Les bases de données SQL sont idéales pour les applications nécessitant un multi- des transactions en ligne comme les systèmes comptables ou les systèmes qui nécessitent des requêtes complexes. Les bases de données NoSQL sont idéales pour les applications ayant besoin de gérer de grandes quantités de données et d'échelle horizontalement comme les systèmes de gestion de contenu, l'analyse en temps réel et les applications IoT.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!