L'une des questions les plus fréquemment posées - quelle base de données dois-je utiliser…
SQL signifie langage de requête structuré. Il a été développé pour la première fois dans les années 1970 par une équipe de chercheurs IBM, les bases de données NoSQL, par contre, ont été utilisées pour la première fois en 1998 par Carlo Strozzi.
La différence la plus courante entre ces deux systèmes de bases de données (DB) est que SQL est relationnel et NoSQL est non relationnel.
Plongeons-nous dans ces deux bases de données pour mieux éclairer votre décision lors de la prochaine base de données pour votre projet.
Database Structure
Parlons de la structuration.
SQL
SQL base de données ont une structure de schéma définie.
Un schéma contient des tables et chaque table contient un nombre défini de colonnes. Cela signifie qu'un utilisateur ne peut pas mettre à jour la table au-delà du nombre de colonnes spécifié dans la table. Ceci est particulièrement utile lorsque vous avez besoin de maintenir l'intégrité des données et également de vous assurer du type de données qui sont enregistrées dans votre base de données.
Chaque table d'une base de données SQL peut être liée. c'est-à-dire que vous pouvez avoir des relations entre les tables. Ces relations peuvent être un à plusieurs, plusieurs à plusieurs ou un à un. Le type de relation que vous implémentez dépend de ce dont vous avez besoin.
Par exemple, considérons la situation hypothétique; nous avons une entreprise avec des utilisateurs, et les utilisateurs peuvent passer des commandes de produits. Ensuite, nous pourrions décider que les utilisateurs peuvent créer plusieurs commandes, mais chaque commande ne peut être créée que par un seul utilisateur. Ce serait une à plusieurs relations, c'est-à-dire un utilisateur à plusieurs commandes. Par conséquent, la structure de table pour les deux tables ressemblera à celle ci-dessous.
Dans notre base de données, nous pourrions avoir une table des utilisateurs, structurée comme ci-dessous,
users_table
----------------------------------------------------
id | name | email
-----------------------------------------------------
1 Idris idris@idrislawal.comAussi, nous pourrions avoir un tableau des commandes
orders_table
---------------------------------------------------------------------------------
id | user_id | order_number
---------------------------------------------------------------------------------
1 1 20000001La solution user_id sur la table des commandes, permet de mapper facilement chaque commande de la table des commandes à l'utilisateur auquel elle appartient. Dans le cas d'une relation un à un, nous pourrions avoir le order_id aussi sur le users_table si nous décidons d'obtenir l'utilisateur par son identifiant de commande associé.
Pour les situations de plusieurs à plusieurs, une table supplémentaire, appelée tableau croisé dynamique, est généralement impliquée. Cela permet à plusieurs enregistrements d'être mappés les uns aux autres. En utilisant l'instance ci-dessus. Nous aurions,
users_table
-------------------------------------------------------------------------------------
id | name | email
-------------------------------------------------------------------------------------
1 Idris idris@idrislawal.comet la table de commande sera
orders_table
---------------------------------------------------------
id | order_number
---------------------------------------------------------
1 2000001puis le tableau croisé dynamique contiendra les deux ID en tant que clés étrangères.
users_orders_table
------------------------------------------------------------------------------
id | order_id | user_id
------------------------------------------------------------------------------
1 1 1Sur la base de cette structure fournie par SQL, vous pouvez facilement écrire des jointures entre des tables qui fourniront des données de différentes tables réunies dans une seule requête.
NoSQL
NoSQL les bases de données ont été conçues pour être plus flexibles que les bases de données SQL, ainsi que pour contenir de plus grandes quantités de données.
Dans les bases de données NoSQL, il n'y a pas de schéma ou de table prédéfini. Il y a des collections, et dans chaque collection, il y a des documents. Cela vous permet d'enregistrer les données sous différentes formes au fur et à mesure qu'elles se présentent. Vous pouvez choisir d'avoir plusieurs documents différents avec des champs différents dans une même collection. Il est également possible de forger manuellement des relations entre les collections. Cependant, ils ne conviennent pas à cette fin. Au lieu de cela, vous pouvez enregistrer tout ce qui est nécessaire pour une seule requête dans la même collection.
Si vous êtes une personne SQL, vous pouvez considérer les collections comme des tables et les documents comme des lignes avec les tables. Cependant, il n'y a aucune restriction sur les colonnes de données que vous pouvez ajouter avec le tableau.
Revenons à notre exemple hypothétique précédemment défini d'une entreprise avec des utilisateurs et des commandes.
Une collection d'utilisateurs peut être définie comme suit:
{id: 1, name: 'idris', email: 'idris@idrislawal.com'}Et la collection de commandes peut être définie comme suit:
{id: 1, order_number: 2000001, user_id:1}Cependant, dans ce cas, nous voulons éviter d'avoir à rejoindre manuellement les deux collections (ce que nous ne devrions pas, dans ce cas). Nous pouvons enregistrer les entrées dans la collection qui sont les plus lues. J'ai décidé (pour cet exemple) que ce sera la collection Commandes.
{id:1, order_number:200001, user{id:1, name: 'idris', email:'idris@idrislawal.com'}}Dans ce cas, nous n'avons plus besoin de lire à partir de la collection d'utilisateurs et de lire uniquement à partir de la collection de commandes, qui contient désormais toutes les données dont nous avons besoin.
Une chose clé à noter ici: Si vous créez une application qui effectue beaucoup de lectures que d'écriture, une option NoSQL vous convient probablement mieux. Parce que vous pourriez avoir toutes vos données enregistrées sur la même collection, et vous pouvez lire à partir de cette source confortablement pour obtenir toutes les données requises.
Cependant, pour une application qui nécessite beaucoup d'écritures (environ 10,000 XNUMX écritures par seconde) à cette échelle, ce n'est pas une bonne idée d'avoir l'option NoSQL où vous devez écrire les mêmes données à plusieurs emplacements. Dans cette situation, une option SQL est probablement plus appropriée, où vous avez des relations existantes avec toutes les tables, et les mêmes données n'ont pas besoin d'être écrites à plusieurs emplacements à plusieurs reprises, la mise à jour des données dans un emplacement peut être disponible pour d'autres tables via la sortie relation. Ceci, bien sûr, ne signifie pas que chacune de ces bases de données ne peut pas gérer l'échelle.
Scaling
Explorons le fonctionnement de la mise à l'échelle.
SQL
Les bases de données SQL ne peuvent pas être mises à l'échelle horizontalement mais uniquement verticalement. Qu'est-ce que cela veut dire?
La mise à l'échelle horizontale signifie diviser les données d'une base de données en plusieurs bases de données pour alléger la charge. Les données SQL ne peuvent cependant pas être fractionnées sur des bases de données distinctes en raison de leur nature stricte. Le bon pour mettre à l'échelle une base de données SQL est d'augmenter le processeur, la mémoire et l'espace disque du serveur de base de données existant, et c'est ce que cela signifie de le mettre à l'échelle verticalement.
NoSQL
Les bases de données NoSQL peuvent être mises à l'échelle à la fois horizontalement et verticalement. Cela est dû à la flexibilité de son stockage de données. Cela permet donc à ses données d'être divisées sur plusieurs bases de données, comme c'est le cas avec la mise à l'échelle horizontale. Il peut également être mis à l'échelle verticalement si nécessaire.
Une chose clé à noter ici: En ce qui concerne la mise à l'échelle, les bases de données SQL et NoSQL peuvent être mises à l'échelle efficacement. Cependant, pour les bases de données SQL, la mise à l'échelle verticale peut être une limitation; un seul serveur de base de données aura une limitation sur la quantité de puissance de calcul qu'il peut transporter.
Il est également important de noter ici que pour la plupart des applications que vous allez créer, vous n'atteindrez peut-être pas le maximum de la capacité de calcul de votre serveur, mais il est utile de garder cela à l'esprit. Cependant, pour les grandes applications d'entreprise mettant en œuvre SQL, une option courante pour surmonter cette limitation est de Sharding.
Qu'est-ce que l'éclatement?
Le sharding est le processus qui consiste à diviser les grandes tables en petits morceaux, appelés fragments. Le partage peut être effectué en partitionnant horizontalement une base de données. Cela ne doit pas être confondu avec la mise à l'échelle horizontale et verticale. Le partitionnement horizontal fait référence au processus de stockage des lignes d'une table dans plusieurs nœuds de base de données. Le partitionnement vertical, en revanche, nécessite la sauvegarde des colonnes d'une table sur différents nœuds. Cela permet à la base de données d'évoluer efficacement et d'améliorer les performances.
Database Examples
SQL
- MySQL - Une base de données open source très populaire. Cependant, la base de données de choix de nombreux développeurs PHP peut également être utilisée avec Node.js, C #, C ++, Java, Perl, Ruby et Python.
- MSSQL - Microsoft SQL offre une grande stabilité car son développement est directement de Microsoft, qui offre également un certain support en termes de reprise après sinistre.
- MariaDB - Ceci a été construit sur MySQL par les créateurs de MySQL, avec l'intention de garder MariaDB comme une version gratuite pour toujours.
- PostgresSQL - Une base de données open source très populaire. Se targue d'être la base de données open source la plus avancée au monde
- Oracle - Ceci est généralement adapté aux solutions d'entreprise d'Oracle avec certaines limitations sur sa version gratuite.
NoSQL
- MongoDB - Probablement la base de données NoSQL la plus connue, courante parmi les développeurs d'applications qui travaillent avec la pile MERN (MongoDB, Express, React, Node) ou la pile MEAN (MongoDB, Express, Angular, Node).
- Firebase - Lancé en 2011 et acquis par Google en 2014, est largement utilisé par les développeurs d'applications Web et mobiles.
- Apache Couch DB - Une base de données NoSQL basée sur des documents qui stocke les données au format JSON.
- Redis: Il s'agit de NoSQL DB, probablement le plus connu pour son utilisation dans le stockage de données avec une durée de vie facultative. Il est également réputé pour sa rapidité.
Conclusion
Vous pouvez créer tout type d'application avec une base de données SQL ou NoSQL. Cela dépend de vos besoins. Si vous envisagez une base de données où vous avez plus de lectures et moins d'écritures, un NoSQL peut être une bonne option. Cependant, si vous envisagez de créer une application avec plus d'écritures que de lectures, un SQL peut être la meilleure solution. En ce qui concerne l'évolutivité, lorsque votre application atteint une échelle très massive, vous pouvez finir par utiliser les deux bases de données.
