Pourquoi utiliser une base de données au lieu de simplement sauvegarder vos données sur disque?
Au lieu d'une base de données, je sérialise simplement mes données en JSON, en les enregistrant et en les chargeant sur le disque si nécessaire. Toute la gestion des données est effectuée sur le programme lui-même, ce qui est plus rapide ET plus facile que d'utiliser des requêtes SQL. Pour cette raison, je n'ai jamais compris pourquoi les bases de données sont nécessaires.
Pourquoi devrait-on utiliser une base de données au lieu de simplement enregistrer les données sur le disque?
- Vous pouvez interroger des données dans une base de données (lui poser des questions).
- Vous pouvez rechercher des données d'une base de données assez rapidement.
- Vous pouvez associer des données de deux tables différentes à l'aide de JOIN.
- Vous pouvez créer des rapports significatifs à partir des données d'une base de données.
- Vos données ont une structure intégrée.
- Les informations d'un type donné ne sont toujours stockées qu'une seule fois.
- Les bases de données sont ACIDE .
- Les bases de données sont tolérantes aux pannes.
- Les bases de données peuvent gérer de très grands ensembles de données.
- Les bases de données sont simultanées; plusieurs utilisateurs peuvent les utiliser en même temps sans corrompre les données.
- Les bases de données évoluent bien.
En bref, vous bénéficiez d'une large gamme de technologies reconnues et éprouvées développées au fil des ans par une grande variété de personnes très intelligentes.
Si vous craignez qu'une base de données soit excessive, consultez SQLite.
Bien que je sois d'accord avec tout ce que Robert a dit, il ne vous a pas dit quand utiliser une base de données au lieu de simplement enregistrer les données sur le disque.
Prenez donc ceci en plus de ce que Robert a dit à propos de l'évolutivité, de la fiabilité, de la tolérance aux pannes, etc.
Pour savoir quand utiliser un SGBDR, voici quelques points à considérer:
- Vous avez des données relationnelles, c'est-à-dire que vous avez un client qui achète vos produits et que ces produits ont un fournisseur et un fabricant
- Vous avez de grandes quantités de données et vous devez être en mesure de localiser rapidement les informations pertinentes
- Vous devez commencer à vous soucier des problèmes précédents identifiés: évolutivité, fiabilité, conformité ACID
- Vous devez utiliser des outils de reporting ou de renseignement pour résoudre les problèmes de l'entreprise
Quant à savoir quand utiliser un NoSQL
- Vous avez beaucoup de données à stocker qui ne sont pas structurées
- Besoins d'évolutivité et de vitesse
- Vous n'avez généralement pas besoin de définir votre schéma à l'avance, donc si vous avez des exigences changeantes, cela pourrait être un bon point
Enfin, quand utiliser des fichiers
- Vous disposez de données non structurées en quantités raisonnables que le système de fichiers peut gérer
- Vous ne vous souciez pas de la structure, des relations
- Vous ne vous souciez pas de l'évolutivité ou de la fiabilité (bien que cela puisse être fait, selon le système de fichiers)
- Vous ne voulez pas ou ne pouvez pas gérer les frais généraux qu'une base de données ajoutera
- Vous traitez des données binaires structurées qui appartiennent au système de fichiers, par exemple: images, PDF, documents, etc.
Une chose que personne ne semble avoir mentionnée est l'indexation des enregistrements. Votre approche est bonne pour le moment, et je suppose que vous disposez d'un très petit ensemble de données et très peu de personnes y accèdent.
À mesure que vous devenez plus complexe, vous créez en fait une base de données. Quel que soit votre nom, une base de données n'est qu'un ensemble d'enregistrements stockés sur disque. Que vous créiez le fichier, ou MySQL , SQLite ou quoi que ce soit qui crée le ou les fichiers, ce sont tous les deux des bases de données.
Ce qui vous manque, c'est la fonctionnalité complexe qui a été intégrée dans les systèmes de base de données pour les rendre plus faciles à utiliser.
La principale chose qui me vient à l'esprit est l'indexation. OK, vous pouvez donc stocker 10 ou 20 ou même 100 ou 1000 enregistrements dans un tableau sérialisé, ou une chaîne JSON et l'extraire de votre fichier et l'itérer relativement rapidement.
Maintenant, imaginez que vous avez 10 000, 100 000, voire 1 000 000 enregistrements. Lorsque quelqu'un essaie de se connecter, vous devrez ouvrir un fichier qui fait maintenant plusieurs centaines de mégaoctets, le charger en mémoire dans votre programme, extraire un tableau d'informations de taille similaire, puis répéter des centaines de milliers d'enregistrements juste pour recherchez l'enregistrement auquel vous souhaitez accéder.
Une base de données appropriée vous permettra de configurer des index sur certains champs dans des enregistrements vous permettant d'interroger la base de données et de recevoir une réponse très rapidement, même avec d'énormes ensembles de données. Combinez cela avec quelque chose comme Memcached , ou même un système de mise en cache de brassage maison (par exemple, stockez les résultats d'une recherche dans un tableau séparé pendant 10 minutes et chargez ces résultats au cas où quelqu'un d'autre chercherait le même chose peu de temps après), et vous aurez des requêtes extrêmement rapides, quelque chose que vous n'obtiendrez pas avec un si grand ensemble de données lorsque vous lisez/écrivez manuellement dans des fichiers.
Une autre chose vaguement liée à l'indexation est le transfert d'informations. Comme je l'ai dit ci-dessus, lorsque vous avez des fichiers de centaines ou de milliers de mégaoctets, vous devez charger toutes ces informations en mémoire, les itérer manuellement (probablement sur le même thread) puis manipuler vos données.
Avec un système de base de données, il fonctionnera sur ses propres threads, ou même sur son propre serveur. Tout ce qui est transmis entre votre programme et le serveur de base de données est une requête SQL et tout ce qui est retransmis, ce sont les données auxquelles vous souhaitez accéder. Vous ne chargez pas l'ensemble de données en mémoire - tout ce que vous envoyez et recevez est une infime fraction de votre ensemble de données total.
TLDR
Il semble que vous ayez pris une décision technique de stockage de données à court terme essentiellement valide pour votre application - vous avez choisi d'écrire un outil de gestion de magasin de données personnalisé.
Vous êtes assis sur un continuum, avec des options pour aller dans les deux sens.
À long terme, vous vous retrouverez probablement (presque, mais pas à 100% certainement) en difficulté, et il serait peut-être préférable de passer à l'utilisation des solutions de stockage de données existantes. Il y a des problèmes de performances spécifiques, très courants et prévisibles, que vous serez obligé de traiter, et il vaut mieux utiliser les outils existants au lieu de lancer les vôtres.
Il semble que vous ayez écrit une (petite) base de données personnalisée, intégrée et directement utilisée par votre application. Je suppose que vous comptez sur un système d'exploitation et un système de fichiers pour gérer l'écriture et la lecture du disque et traiter la combinaison comme un magasin de données.
Quand faire ce que tu as fait
Vous êtes assis à un endroit idéal pour le stockage de données. Un magasin de données de système d'exploitation et de fichiers est incroyablement pratique, accessible et portable multiplateforme. La combinaison existe depuis si longtemps que vous êtes certain d'être pris en charge et de faire fonctionner votre application sur presque toutes les configurations de déploiement standard.
C'est aussi une combinaison simple pour écrire du code - API est assez simple et basique, et il faut relativement peu de lignes de code pour le faire fonctionner.
En règle générale, il est idéal de faire ce que vous avez fait lorsque:
- Prototypage de nouvelles idées
- Création d'applications dont il est très peu probable qu'elles aient besoin d'évoluer, en termes de performances
- Contraint par des circonstances inhabituelles, telles que le manque de ressources pour installer une base de données
Alternatives
Vous êtes sur un continuum d'options, et il y a deux `` directions '' que vous pouvez suivre à partir d'ici, ce que je pense être `` vers le bas '' et `` vers le haut '':
Vers le bas
C'est l'option la moins probable à appliquer, mais elle est là pour des raisons d'exhaustivité:
Vous pouvez, si vous le souhaitez, descendre vers le bas , c'est-à-dire contourner complètement le système d'exploitation et le système de fichiers et vraiment écrire et lire directement à partir du disque. Ce choix n'est généralement pertinent que dans les cas où une efficacité extrême est requise - pensez, par exemple, à un lecteur minimal/minuscule MP , sans suffisamment RAM pour un système d'exploitation entièrement fonctionnel, ou quelque chose comme Wayback Machine , qui nécessite des opérations d'écriture de données de masse incroyablement efficaces (la plupart des magasins de données échangent des écritures plus lentes pour des lectures plus rapides, car c'est la très grande majorité cas d'utilisation plus courant pour presque toutes les applications).
En haut
Il existe plusieurs sous-catégories ici - cependant, elles ne sont pas exactement exclusives. Certains outils couvrent les deux, fournissant des fonctionnalités dans chacun, certains peuvent complètement passer du travail dans un mode à celui dans l'autre, et certains peuvent être superposés, fournissant des fonctionnalités différentes à différentes parties de votre application.
Des magasins de données plus puissants
Il se peut que vous deviez avoir besoin de stocker des volumes de données de plus en plus élevés, tout en comptant sur votre propre application pour gérer la complexité de manipulation des données. Une gamme complète de magasins de valeurs-clés est à votre disposition, avec différents niveaux de prise en charge pour les fonctions connexes. NoSQL les outils entrent dans cette catégorie, ainsi que d'autres.
C'est le chemin évident pour évoluer lorsque les éléments suivants décrivent votre application:
- Il est particulièrement lourd en lecture
- Vous êtes d'accord avec un compromis sur des performances plus élevées pour des garanties de cohérence inférieures (à court terme) (beaucoup offrent une "cohérence éventuelle").
- Gère "directement" la plupart de la manipulation des données et le manque de cohérence (dans la pratique, vous finirez probablement par utiliser un outil tiers au début, mais vous finirez par l'intégrer dans votre application ou dans une couche intermédiaire écrite personnalisée) .
- Vous cherchez à faire évoluer massivement la quantité de données que vous stockez et/ou votre capacité à les parcourir, avec des exigences de manipulation des données "relativement simples".
Il y a une certaine marge de manœuvre ici - vous pouvez forcer une meilleure cohérence de lecture, pour des lectures plus lentes. Divers outils et options fournissent des API de manipulation de données, d'indexation et d'autres options, qui peuvent être plus ou moins adaptées pour écrire facilement votre application spécifique. Donc, si les points ci-dessus décrivent presque complètement votre application, vous pourriez être "assez proche" pour travailler avec une solution de stockage de données plus puissante.
Exemples connus: CouchDB , MongoDB , Redis , des solutions de stockage cloud comme Microsoft Azure , Google App Data Store et ECE d'Amazon.
Moteurs de manipulation de données plus complexes
La famille "SQL" d'applications de stockage de données, ainsi que toute une gamme d'autres, sont mieux décrites comme des outils de manipulation de données que de purs moteurs de stockage. Ils offrent un large éventail de fonctionnalités supplémentaires, au-delà du stockage des données, et souvent au-delà de ce qui est disponible dans le magasin de valeurs-clés. Vous voudrez emprunter ce chemin lorsque:
- Vous devez absolument avoir une cohérence de lecture, même si cela signifie que vous en subirez une baisse de performances.
- Vous cherchez à effectuer efficacement une manipulation de données très complexe - pensez à des opérations JOIN et UPDATE très complexes, cubes de données et découpage, etc ...
- Vous pouvez accepter la rigidité de la performance (pensez aux formats de stockage de données fixes et forcés, tels que les tableaux, qui ne peuvent pas être modifiés facilement et/ou efficacement).
- Vous disposez des ressources nécessaires pour gérer un ensemble d'outils et d'interfaces souvent plus complexes.
C'est la façon la plus "traditionnelle" de penser à une base de données ou à un magasin de données, et elle existe depuis bien plus longtemps - donc il y a un beaucoup qui est disponible ici, et il y a souvent beaucoup de complexité à traiter. C'est possible, bien que cela nécessite une certaine expertise et des connaissances, et que vous construisiez des solutions simples/évitez une grande partie de la complexité - vous finirez très probablement par utiliser des outils et des bibliothèques tiers pour en gérer la plupart pour vous.
Des exemples bien connus sont MySQL , SQL Server , Oracle's Database et DB2 .
Externaliser le travail
Il existe plusieurs outils et bibliothèques tiers modernes qui s'interposent entre vos outils de stockage de données et votre application pour vous aider à gérer la complexité.
Ils tentent au départ de supprimer la plupart ou la totalité du travail consacré à la gestion et à la manipulation des magasins de données et, idéalement, vous permettent de faire une transition en douceur vers la complexité uniquement quand et si cela est nécessaire. Il s'agit d'un domaine actif de l'entrepreneuriat et de la recherche, avec quelques résultats récents qui sont immédiatement accessibles et utilisables.
Des exemples bien connus sont MVC tools ( Django , Yii ), Ruby on Rails , et Datomic . Il est difficile d'être juste ici, car il existe littéralement des dizaines d'outils et de bibliothèques qui agissent comme des enveloppes autour des API de divers magasins de données.
PS: si vous préférez les vidéos au texte, vous voudrez peut-être regarder certaines des vidéos liées à la base de données de Rich Hickey; il fait un bon travail d'élucider la plupart des réflexions qui entrent dans le choix, la conception et l'utilisation d'un magasin de données.
Lorsque vous avez des données simples, comme une liste de choses que vous décrivez dans les commentaires de votre question, alors une base de données SQL ne vous donnera pas grand-chose. Beaucoup de gens les utilisent encore, car ils savent que leurs données peuvent devenir plus compliquées avec le temps, et il y a beaucoup de bibliothèques qui rendent le travail avec la base de données trivial.
Mais même avec une simple liste que vous chargez, conservez en mémoire, puis écrivez si nécessaire, peut souffrir d'un certain nombre de problèmes:
Une interruption anormale du programme peut perdre des données ou, lors de l'écriture de données sur le disque, quelque chose ne va pas et vous pouvez finir par tuer tout le fichier. Vous pouvez rouler vos propres mécanismes pour gérer cela, mais les bases de données gèrent cela pour vous en utilisant des techniques éprouvées au combat.
Si vos données commencent à devenir trop volumineuses et à se mettre à jour trop souvent, la sérialisation de toutes vos données et leur sauvegarde vont être un gros porc de ressources et tout ralentir. Vous devriez commencer à travailler sur la façon de partitionner les choses, donc ce ne sera pas si cher. Les bases de données sont optimisées pour enregistrer uniquement les éléments qui changent sur le disque d'une manière tolérante aux pannes. De plus, ils sont conçus pour vous permettre de charger rapidement les petits morceaux de données dont vous avez besoin à tout moment.
De plus, vous n'avez pas besoin d'utiliser des bases de données SQL. Vous pouvez utiliser NoSQL "bases de données", ce que beaucoup font, utilisez simplement JSON pour stocker les données. Mais cela se fait d'une manière tolérante aux pannes et d'une manière où les données peuvent être divisées, interrogées et divisées intelligemment sur plusieurs ordinateurs.
De plus, certaines personnes confondent les choses. Ils peuvent utiliser un magasin de données NoSQL comme Redis pour stocker les informations de connexion. Utilisez ensuite des bases de données relationnelles pour stocker des données plus complexes là où elles doivent effectuer des requêtes plus intéressantes.
Je vois que beaucoup de réponses se concentrent sur le problème de la concurrence et de la fiabilité. Les bases de données offrent d'autres avantages en plus de la simultanéité, de la fiabilité et des performances. Ils permettent de ne pas déranger la façon dont les octets et les caractères sont représentés dans la mémoire. En d'autres termes, les bases de données permettent au programmeur de se concentrer sur "quoi" plutôt que "comment".
L'une des réponses mentionne les requêtes. "Poser une question à une base de données SQL" est bien adapté à la complexité d'une question. Au fur et à mesure que le code évolue au cours du développement, des requêtes simples telles que "tout récupérer" peuvent facilement être développées pour "tout récupérer lorsque la propriété1 est égale à cette valeur, puis trier par la propriété2" sans que le programmeur ne souhaite optimiser la structure des données pour une telle requête. Les performances de la plupart des requêtes peuvent être accélérées en créant un index pour une certaine propriété.
Les autres avantages sont les relations. Avec les requêtes, il est plus propre de croiser les données de différents ensembles de données, puis d'avoir des boucles imbriquées. Par exemple, la recherche de tous les messages de forum d'utilisateurs qui ont moins de 3 messages dans un système où les utilisateurs et les messages sont différents ensembles de données (ou tables de base de données ou objets JSON) peut être effectuée avec une seule requête sans sacrifier la lisibilité.
Dans l'ensemble, les bases de données SQL sont meilleures que les tableaux simples si le volume de données peut être volumineux (disons plus de 1000 objets), l'accès aux données dans des parties non triviales et différentes de l'accès au code à différents sous-ensembles de données.
Un système de fichiers correspond à la description d'une base de données NoSQL, donc je dirais que vous devriez certainement envisager de l'utiliser lorsque vous décidez de la façon de stocker vos données et ne pas simplement les ignorer au profit du SGBDR, comme certaines réponses semblent le suggérer ici.
Un problème avec les systèmes de fichiers (et NoSQL en général) concerne la gestion des relations entre les données. Si ce n'est pas un bloqueur majeur ici, alors je dirais sauter le RDBMS pour l'instant. N'oubliez pas non plus les aspects positifs de l'utilisation d'un système de fichiers comme stockage:
- Administration zéro
- Faible complexité, facile à installer
- Fonctionne avec n'importe quel système d'exploitation, langue, plate-forme, bibliothèques, etc.
- Le seul paramètre de configuration est le répertoire
- Trivial à tester
- Trivial à examiner avec les outils existants, sauvegarder, modifier, etc.
- Bonnes caractéristiques de performance et bien réglé par le système d'exploitation
- Facile à comprendre pour tout développeur
- Pas de dépendances, pas de pilotes supplémentaires
- Le modèle de sécurité est simple à comprendre et fait partie intégrante du système d'exploitation
- Les données ne sont pas accessibles de l'extérieur
( source )
Les systèmes de fichiers sont un type de base de données. Peut-être pas un SGBDR comme tout le monde en parle, mais certainement une base de données au sens strict. Vous fournissez des clés (nom de fichier) pour rechercher des données (contenu de fichier), qui ont un stockage abstrait et une API par laquelle votre programme communique.
Donc, vous utilisez une base de données. Les autres articles peuvent discuter des vertus des différents types de bases de données ...
Une base de données est nécessaire si vous avez plusieurs processus (utilisateurs/serveurs) modifiant les données. Ensuite, la base de données sert à les empêcher d'écraser les modifications les uns des autres.
Vous avez également besoin d'une base de données lorsque vos données sont plus volumineuses que la mémoire. De nos jours, avec la mémoire dont nous disposons, cela rend en effet obsolète l'utilisation des bases de données dans de nombreuses applications.
Votre approche est certainement meilleure que le non-sens des "bases de données en mémoire". Qui sont essentiellement votre approche, mais avec beaucoup de frais généraux ajoutés.
Vous devez toujours vous demander si une application particulière a besoin d'un SGBDR. Trop d'applications sont construites avec un processus de conception qui suppose automatiquement tous les outils et cadres requis au début. Les bases de données relationnelles sont si courantes et de nombreux développeurs ont travaillé sur des applications similaires comme auparavant, qu'elles sont automatiquement incluses avant le démarrage du projet. De nombreux projets peuvent s'en tirer, alors ne jugez pas trop sévèrement.
Vous avez démarré votre projet sans un, et ça marche. Il était plus facile pour vous de le mettre en place sans attendre SQL. Il n'y a rien de mal à cela.
À mesure que ce projet prend de l'expansion et que les exigences deviennent plus compliquées, certaines choses vont devenir difficiles à construire. Jusqu'à ce que vous recherchiez et testiez d'autres méthodes, comment savoir laquelle est la meilleure? Vous pouvez demander sur Programmeurs et sarcler les flammes et 'ça dépend' pour répondre à cette question. Une fois que vous l'avez appris, vous pouvez considérer le nombre de lignes de code que vous êtes prêt à écrire dans votre langue pour gérer certains des avantages d'une base de données. À un moment donné, vous réinventez la roue.
La facilité est souvent relative. Il existe certains cadres qui peuvent créer une page Web et connecter un formulaire à une table de base de données sans que l'utilisateur n'écrive de code. Je suppose que si vous avez du mal avec la souris, cela pourrait être un problème. Tout le monde le sait, ce n'est pas évolutif ou flexible parce que Dieu nous en préserve, vous avez étroitement couplé tout à l'interface graphique. Un non-programmeur vient de construire un prototype; beaucoup de YAGNI à trouver ici.
Si vous préférez apprendre un ORM manipulé par la langue de votre choix au lieu d'apprendre SQL, allez-y, mais essayez d'installer, de créer une table et de tirer certaines données d'une base de données populaire avec SQL (Select * From; ce n'est pas un truc époustouflant). C'est facile à faire. C'est pourquoi quelqu'un les a créés en premier lieu. Cela ne semble pas être un investissement énorme pour prendre une décision éclairée. Vous pourriez également faire un test de performance.
Enregistrer les données sur le disque [~ # ~], c'est [~ # ~] l'écrire dans une base de données, surtout si vous placez chaque objet dans son propre fichier le nom du fichier étant la clé de l'enregistrement. Et pour minimiser les temps de recherche pour la lecture du fichier, créez des sous-répertoires basés sur les premiers caractères de la clé.
Par exemple, key = ghostwriter irait dans g/ho/stwriter.json ou g/h/o/stwriter.json ou g/ho/ghostwriter.json ou g/h/o/ghostwriter.json. Choisissez votre schéma de dénomination en fonction de la distribution de vos clés. Si ce sont des numéros de séquence, 5/4/3/12345.json est meilleur que l'inverse.
C'est une base de données et si elle fait tout ce dont vous avez besoin, faites-le de cette façon. De nos jours, cela s'appellerait une base de données NoSQL comme GDBM ou Berkeley db. Tant de choix. Déterminez d'abord ce dont vous avez besoin, puis créez une bibliothèque d'interface pour traiter les détails, peut-être une interface get/set comme memcached ou une interface CRUD, puis vous pourrez échanger des bibliothèques si vous devez changer le format de la base de données pour une avec des caractéristiques différentes.
Notez que certaines bases de données SQL comme PostgreSQL et Apache Derby DB, vous permettront de faire des requêtes SQL en plus de nombreux formats NoSQL, y compris vos propres bases de données locales. Je ne suis pas sûr de MyBatis mais il peut être similaire.
Évitez le battage médiatique NoSQL. Découvrez les fonctionnalités, testez les performances et les capacités, puis choisissez en fonction de leur adéquation avec les besoins de votre application.
http://www.hdfgroup.org/HDF5/ est encore un autre format de magasin de données intéressant et largement utilisé que les gens ne considèrent pas souvent.
Dès que les données sont mises à jour simultanément, l'approche utilisant une base de données (il pourrait bien s'agir d'une base de données en mémoire) sera probablement plus correcte et plus performante, alors qu'en même temps votre code reste simple, car vous n'avez tout simplement pas de s'inquiéter des mises à jour simultanées, des transactions, de la mise en cache, des E/S asynchrones et tout cela.