Je travaille sur un projet où j'essaie de décider entre l'utilisation d'une base de données relationnelle SQL standard ou des objets JSON pour stocker des données sur un événement ou une activité.
Le projet stockera des données sur plusieurs types d'événements, j'ai donc décidé de décrire un seul type d'événement pour cette question.
L'événement de musique en direct (décrit en détail à l'aide du schéma JSON au bas de cette question) est un objet qui stocke des données telles que le lieu de l'événement, l'heure / la date de l'événement et le coût de l'événement. L'objet d'événement de musique en direct a à la fois un à un (événement -> nom, événement -> description) et un à plusieurs (événement -> lieux, événement -> dates, événement -> types de billets ) des relations. En outre, l'objet d'événement peut contenir un ou plusieurs ID d'intervenant, qui sont liés à l'objet d'intervenant. L'objet interprète stocke des données sur les musiciens qui se produisent lors de l'événement musical en direct.
Les données seront interrogées par les utilisateurs en utilisant à la fois des événements simples ("Find me events with 'x' name") et complexes ("Find me events with 'x' music genre and 'y' within a radius of 'z' from my current) emplacement "). Les données seront soumises par les utilisateurs à l'aide d'un formulaire Web.
Comme vous pouvez probablement le voir à partir du schéma JSON défini, j'allais à l'origine utiliser des objets JSON pour stocker ces données, mais j'ai entendu des gens dire que parce que mes données sont purement relationnelles, je devrais m'en tenir aux anciennes méthodes.
J'apprécierais toute réflexion sur les avantages et les inconvénients de chaque approche compte tenu de mes besoins. Si vous avez besoin de clarifier quoi que ce soit, n'hésitez pas à demander.
{
"event": {
"eventID":{
"type":"string"
},
"eventType":{
"type":"array",
"eventTypeItem":{
"type":"string"
}
},
"eventName":{
"type":"string"
},
"eventDescription":{
"type":"string"
},
"eventVenueList":{
"type":"array",
"eventVenueListID":{
"type":"integer"
}
},
"eventURL":{
"type":"string"
},
"eventTwitter":{
"type":"string"
},
"eventFB":{
"type":"string"
},
"eventInstagram":{
"type":"string"
},
"eventEmail":{
"type":"string",
"format":"email"
},
"eventContactPerson":{
"type":"string"
},
"eventDoorTime": {
"type":"string",
"format":"date-time"
},
"eventPerformerIDList":{
"type":"array",
"liveMusicPerformerID":{
"type":"integer"
}
},
"eventSetList":{
"type":"array",
"eventPerformerID":{
"type":"integer"
},
"eventPerformerStartTime":{
"type":"string",
"format":"date-time"
},
"eventPerformerEndTime":{
"type":"string",
"format":"date-time"
}
},
"eventDateList": {
"type":"array",
"eventDateItem": {
"type":"string",
"format":"date-time"
}
},
"eventDateStartTime": {
"type":"string",
"format":"date-time"
},
"eventDateEndTime": {
"type":"string",
"format":"date-time"
},
"eventTicket":{
"type":"array",
"eventTicketType":{
"type":"string"
},
"eventTicketLowPrice":{
"type":"number"
},
"eventTicketHighPrice":{
"type":"number"
},
"eventDatesAdvancePrice": {
"type":"number"
}
}
},
"performer": {
"performerID": {
"type":"integer"
},
"performerType": {
"type":"string"
},
"performerName": {
"type":"string"
},
"performerAlternateName": {
"type":"array",
"performerAlterateNameItem":{
"type":"string"
}
},
"performerGenreList": {
"type":"array",
"performerGenreItem":{
"type":"string"
}
},
"performerURL": {
"type":"string"
}
}
}
Réponses:
Je pense que votre question se résume vraiment à: quand dois-je utiliser une approche NoSQL vs RDBMS? Vous avez opté pour JSON tôt (une décision NoSQL), peut-être parce que vous avez des consommateurs Ajax.
La réponse, bien sûr, au moment d'utiliser les approches NoSQL par rapport aux SGBDR est essentiellement le type de données avec lesquelles vous travaillez et les consommateurs que vous prévoyez d'avoir. Si vos données sont essentiellement relationnelles (hiérarchies assez plates, pas de types de données étranges comme des images ou du son, des relations prévisibles entre les schémas qui peuvent être facilement décrits dans les clés), et vos consommateurs devraient éventuellement inclure des personnes qui souhaitent effectuer des requêtes de Business Intelligence (interrogation ad hoc), alors un SGBDR est la voie à suivre. Il est assez facile de transformer une requête en représentation JSON, donc cela n'alourdit pas considérablement vos consommateurs Ajax - cela ajoute juste un peu de codage de transformation dans vos points de terminaison (REST / SOAP / autre). inversement, si vos données sont très hiérarchisées (schémas profonds), contiennent des types de données étranges comme des images, du son, de la vidéo, etc., il existe peu de relations entre les entités, et vous savez que vos utilisateurs finaux ne feront pas de BI, alors NoSQL / stockage JSON peut être approprié.
Bien sûr, même ces directives générales ne sont pas solides. La raison pour laquelle Google a développé Google File System, MapReduce (travail qui a été utilisé par Doug Cutting pour créer Hadoop chez Yahoo) et plus tard BigQuery (une façon NoSQL orientée [sans schéma] de gérer des données à grande échelle) était précisément parce qu'ils avaient beaucoup de Les demandes de BI, et ils n'ont pas pu obtenir d'approches relationnelles pour évoluer à l'échelle tera / peta / exa / zetta / yotta qu'ils essayaient de gérer. La seule approche pratique consistait à évoluer, en sacrifiant une partie de la convivialité des requêtes ad hoc fournies par un SGBDR et en substituant un algorithme simple (MapReduce) qui pourrait être codé assez facilement pour une requête donnée.
Compte tenu de votre schéma ci-dessus, ma question serait essentiellement: pourquoi ne pas utiliser un SGBDR? Je ne vois pas beaucoup de raisons de ne pas le faire. Notre profession est censée être axée sur l'ingénierie et non sur la mode, donc notre instinct devrait être de choisir la solution la plus simple qui fonctionne, non? Je veux dire, vos points de terminaison peuvent avoir à faire une petite traduction si vos consommateurs sont Ajaxy, mais vos données semblent très plates et il semble probable que les utilisateurs professionnels voudront faire toutes sortes de requêtes ad hoc sur des choses comme les événements musicaux (qui l'événement a été le plus fréquenté à moins de 50 miles de notre capitale l'année dernière?)
«N'allez pas voir les elfes pour obtenir des conseils, car ils diront non et oui. - Frodon
la source
Je pense qu'il y a plus de considérations ici que vous ne cherchez peut-être pas. Il y a ici deux grandes préoccupations:
Espace de rangement
Il y a beaucoup d'opinions sur la raison pour laquelle utiliser no-sql ou RDBMS store pour vos données. L'un des éléments les plus importants que nous pensions utiles était que nous pouvons facilement définir et stocker des objets json dans le stockage sans avoir à vous soucier de définir sa structure complète ou sa relation entre différents types d'objets. Certaines des autres raisons d'utiliser une base de données NoSql seraient la possibilité d'auto-partitionner les données, les recherches basées sur l'emplacement et la maintenance facile. Il existe de nombreuses bonnes bases de données NoSql, ma préférence personnelle est MongoDB. Cependant, si vous n'avez jamais utilisé la base de données NoSql auparavant, il existe une courbe d'apprentissage définie lorsque vous apprenez à recâbler votre esprit. La plupart d'entre nous utilisent le SGBDR depuis un certain temps maintenant et il faut un effort conscient pour sortir de cette habitude. De plus, vous vous retrouverez à vouloir refaire votre modèle de données au fur et à mesure que vous poursuivez vos efforts et vous aurez une meilleure compréhension des concepts. Si la capacité de refactoriser ou de remodeler n'est pas une option pour votre projet, je vous suggère de vous en tenir à ce que vous connaissez déjà le mieux.
Chercher
Si vous avez l'intention de fournir tout type de recherche utilisable, je vous suggère fortement d'utiliser un moteur de recherche de texte dédié tel que SOLR pour effectuer vos recherches. Les recherches de texte sont lentes et si vous avez plusieurs fragments, encore plus lentement. SOLR prend en charge des recherches de texte extrêmement rapides, y compris des paramètres de recherche pondérés, des recherches basées sur la localisation et bien plus encore. SOLR n'est cependant pas adapté en tant que stockage principal de vos données. Cela signifie que vous devrez créer des mécanismes pour la double insertion et la mise à jour de votre base de données principale et de votre couche SOLR lors de l'ajout ou de la mise à jour d'événements. De plus, vous devrez garder le SOLR mis à jour ultérieurement en supprimant tous les événements obsolètes / terminés.
Bien que cela semble être beaucoup de travail supplémentaire, vous vous remercierez pour la prévoyance d'utiliser un moteur de recherche de texte intégral plus tard. Aucune des bases de données NoSql ou RDBMS ne se rapproche des performances et de l'agilité de SOLR / Lucene.
la source
Tout d'abord, si vous essayez de stocker des données JSON dans n'importe quel stockage mais pas dans une base de données NoSQL , je vous découragerais certainement d'utiliser JSON. La raison en est que si vous stockez vos données sous forme de fichier JSON, par exemple, il sera extrêmement lent de l'ouvrir, de l'analyser, de la parcourir, etc.
Cela dit, je peux limiter votre question à: Quels sont les avantages et les inconvénients de NoSQL et RDBMS ? Et il a déjà été répondu des milliers de fois sur le net.
En reclassant votre projet, vous pouvez bien sûr utiliser NoSQL ou RDBMS ; Cependant, ce que je peux généralement vous recommander, c'est de sortir des sentiers battus et de rechercher les autres facteurs moins visibles qui pourraient vous aider à choisir entre les deux options. Essayez de voir quelle option pourrait accélérer le développement? Ce qui est plus adapté aux autres membres de l'équipe - si vous n'êtes pas un développeur unique. Si vous vendez cela, lequel est moins cher, plus facile et généralement plus adapté à vos clients non développeurs?
De cette façon, vous pouvez enfin décider de la voie à suivre, sinon il sera très difficile de décider en fonction des informations fournies, car les deux options pourraient très bien convenir.
la source
Dans la plupart des applications, il est nécessaire de
Afin de satisfaire aux exigences de l'article 1, une méthode de persistance des données est nécessaire. En règle générale, si le volume de données est très faible et que le type de données est simple et ne nécessite pas de capacités de recherche étendues, une structure de fichiers simple peut être utilisée. À mesure que les données deviennent plus complexes, une structure XML (ou même JSON) peut être utilisée avec les données toujours stockées dans des fichiers. La recherche devient cependant plus problématique. À mesure que le volume de données augmente et que la complexité des recherches augmente, une base de données est normalement sélectionnée, ce qui fournit des méthodes standard pour la persistance des données, les requêtes, etc. Les bases de données peuvent être conçues pour gérer de grands volumes de données et stocker, récupérer et rechercher les données rapidement et efficacement. .
Afin de répondre aux exigences de l'article 2, il existe différentes méthodes pour permettre l'échange de données entre les systèmes, y compris XML, JSON, etc.
Ces méthodes permettent à la structure de données d'être définie par un utilisateur et sont indépendantes de la langue, ce qui permet à un système différent d'échanger des données.
Dans votre cas particulier, vous utilisez correctement JSON décrit un ensemble d'événements musicaux. Bien que vous puissiez stocker les données au format JSON en recherchant ces données, le nombre d'événements musicaux augmentera sera lent et inefficace.
En utilisant une approche de séparation des préoccupations, une meilleure approche consiste à collecter les données, à les stocker dans une base de données, à effectuer votre requête en fonction des entrées des utilisateurs dans la base de données, puis à renvoyer les résultats au format JSON côté client pour afficher les données.
Un problème supplémentaire avec l'approche JSON est la modification de la structure des données. Actuellement, votre structure est relativement simple. Vous pouvez utiliser cette structure pendant plusieurs mois, puis un champ supplémentaire est identifié. Que faites-vous ensuite avec tous vos objets JSON existants? Leur mise à jour serait problématique.
Si vous avez utilisé une base de données, l'ajout d'un champ supplémentaire est relativement simple et seul votre code pour générer le JSON devrait être modifié en un seul endroit, vous donnant ainsi tout le nouveau JSON avec le nouveau champ.
En bref, utilisez chaque technologie pour ce qu'elle a été conçue pour JSON pour l'échange de données et une base de données pour la persistance des données.
la source
Je pense que vous aurez plus de succès à utiliser NoSQL que SQL pour stocker ces données, en raison des requêtes que vous devez faire.
Le fait que certaines données soient purement relationnelles ne signifie pas non plus qu'elles doivent être conservées dans certains SGBDR (SQL). Les données relationnelles de l'OMI se traduiraient mieux en bases de données graphiques.
Bien sûr, vous pouvez également écrire les requêtes en SQL, mais les performances seront terribles en raison du nombre de jointures que vous devrez avoir (étant donné que vos données seront quelque peu normalisées et pas toutes dans une seule table d'événements).
Mais en conclusion, vous aurez plus de liberté en utilisant NoSQL (donc JSON ou un autre format pris en charge par la base de données) étant donné que vous pouvez modifier votre schéma à l'avenir sans prendre en compte les données déjà persistantes.
En considérant NoSQL, vous pouvez également consulter des bases de données graphiques si vous prévoyez d'utiliser des requêtes très complexes, car celles-ci vous donneront des avantages pour les créer facilement et les exécuter très rapidement.
la source
Je pense que vous devriez utiliser les deux et je ne vois pas cela comme une décision «contre».
Une base de données relationnelle est logique pour un stockage et une récupération rapides et efficaces des données qui ont des propriétés relationnelles.
JSON est un excellent format de données car il est simple, léger et idéal pour faire circuler des données brutes dans un format très basique avec une syntaxe adaptée au stockage et à l'échange d'informations textuelles. C'est idéal pour passer de petites quantités de données entre un navigateur et un serveur. Ce n'est pas dans un format aussi facile à utiliser pour les requêtes de données de type relationnel.
Je recommanderais donc SQL pour le stockage des données et JSON pour le format de transport des données.
Il est vrai qu'il n'y a pas d'options de valeur-clé SQL telles que Mongo, Redis, etc. Celles-ci auraient l'avantage d'un mappage peut-être plus simple au format JSON mais sont généralement un peu plus difficiles à utiliser pour les requêtes. Le principal obstacle avec eux est la méconnaissance de la communauté informatique générale, en particulier par rapport à SQL qui est si bien connu et dispose d'un large éventail de ressources et de connaissances disponibles pour presque toutes les situations imaginables.
la source