I ai une application Web qui utilise une base de données relationnelle (MySQL). Nous avons ajouté une nouvelle fonctionnalité qui permettra à certains utilisateurs de « formes » construct de manière dynamique à partir d'un pool d'éléments de formulaire en option et distribuer ces formulaires pour l'achèvement / soumission à d'autres utilisateurs.
Le problème réside dans le stockage des soumissions de formulaire dûment rempli. Chaque formulaire peut et varier le nombre et la combinaison des éléments de formulaire, et avec une base de données relationnelle mes options sont quelque peu limitées à créer dynamiquement une nouvelle table pour tenir les soumissions de chaque forme (semble comme un mauvais chemin pour aller vers le bas) ou le stockage chacune des formes présentées comme JSON dans une colonne de texte (perdre toutes les capacités d'interrogation utiles de SGBDR)
Je n'ai jamais utilisé MongoDB dans un projet de production avant, mais je pense qu'il pourrait être une bonne idée d'utiliser ma MySQL base de données relationnelle pour stocker toutes les formes créées par certains utilisateurs de mon application, puis stocker tous les conclusions de MongoDB avec chaque document faisant référence à la UUID du formulaire dans MySQL.
Le premier inconvénient que je peux penser à cette approche est qu'il n'y a pas d'intégrité référentielle entre les soumissions de formulaire et les formulaires situés dans MySQL. Si je supprime un formulaire dans MySQL, toutes les soumissions de formulaire devront être supprimés manuellement (si je veux reproduire l'effet « Cascade »)
Aurais-je stocker toutes mes soumissions de formulaire pour toutes mes formes en une seule collection MongoDB sous forme de documents individuels? Tout conseil est grandement appréciée. :)
EDIT 1
Sur la base de la documentation ici: http: //www.mongodb .org / écran / DOCS / Utilisation + a + grand + + Nombre de + collections
J'envisage maintenant la création d'une nouvelle collection de tenir toutes les soumissions de chaque type de formulaire unique.
EDIT 2
Après mûre réflexion minutieuse et les conseils des autres que j'ai décidé d'abandonner mon approche à double base de données pour résoudre ce problème en faveur d'un schéma-base de données relationnelle que je pense résout le problème de la création de formulaires dynamiques et enregistrer les soumissions de formulaire de telle sorte qu'ils sont facilement interrogeables pour les rapports complexes.
Pour l'essentiel tous les enregistrements de « formes » représente une forme unique qui a été construit par un utilisateur. « Forms_fields » a une clé étrangère qui fait référence à la forme et un de type ENUM avec les options:
1. case à cocher
2. textfield
3. textarea
4. sélectionnez
5. multi-sélection
6. date
« forms_fields_options » contient toutes les « options » un champ de sélection aurait.
Avec ces trois tableaux, les utilisateurs peuvent créer des formulaires personnalisés.
Quand un autre utilisateur remplit et soumet le formulaire, un dossier est créé dans forms_submissions. Pour chaque champ, un enregistrement correspondant sera créé dans « forms_submissions_fields » qui fait référence à la soumission de formulaire et le forms_fields_id. La table finale, « forms_submissions_options_multiselect » est essentiellement une jointure table pour indiquer les options d'un champ de formulaire multi-sélection de l'utilisateur sélectionné.
3 Réponses :
Je pense que vous oubliez que vous négligez le fait qu'un SGBDM permettra des choses comme EAV (valeur-Attribut-valeur, qui est horrible si vous l'utilisez, mais peut être grande dans la modération) ou de rejoindre des tables, pour construire plusieurs relations ordonnées d'une forme unique à divers éléments de forme.
Je ne suggère pas qu'un SGBDM est parfait pour tout, voire de votre situation, mais je sais que j'ai dû créer des systèmes similaires et que je n'ai jamais eu à aller Nosql pour les soutenir de manière raisonnable.
Edit: plus au point ... Stockage des valeurs de champ réels vous propose une autre relation de l'élément de forme d'origine, mais si votre interface utilisateur garde les choses cohérentes, vous pouvez le faire génériquement. Je dirais que je regarderais plus loin dans lesquels les solutions NOSQL permettent aux types particuliers de requête basée sur la valeur que vous avez besoin pourrait amener plus de lumière sur vos options.
Merci pour vos conseils. J'ai essayé de construire un schéma de base de données que je crois résoudra mon problème en utilisant uniquement MySQL. L'esprit lui donne un look et me dise ce que vous pensez? Il est maintenant posté dans ma question sous 'Edit 2'
Ceci peut certainement être fait dans SQL en utilisant EAV . Donc, NOSQL n'est définitivement pas nécessaire.
L'utilisation d'un outil comme MongoDB pourrait être un bon ajustement pour les résultats flexibles que vous souhaitez économiser, mais il existe des compromis ici, mais ils ne sont peut-être pas exactement ce que vous attendez.
... stocker chacun des formulaires soumis en tant que JSON dans une colonne de texte ( perdant toutes les capacités de requête utiles des RDBMSS )
Combien de soumissions de formulaire envisagez-vous d'avoir? Quel type d'interrogation comptez-vous faire?
Mon expérience avec MongoDB est qu'elle fonctionne très mal lorsque vous interrogez contre des données qui ne sont pas indexées. De plus, l'agrégation est généralement effectuée en lots en utilisant la carte / réduction ( ou le nouveau cadre d'agrégation ).
Si vous comparez la complexité de faire des rouleaux ou de l'efficacité de faire des requêtes, il n'est pas clair que MongoDB est nettement meilleur ici que EAV.
Si je supprime un formulaire dans MySQL, toutes les soumissions de formulaire devront être supprimées manuellement
Curieusement, j'ai rarement vu cela comme un problème car vous ne supprimerez probablement jamais le formulaire dans SQL. Vous ferez probablement une suppression logique et ne rien enlever vraiment rien. Donc, c'est probablement un point de théâtre.
Je stockerais-je toutes mes soumissions de formulaire pour toutes mes formes dans une seule collection de MongoDB en tant que documents individuels?
Encore une fois dépend du nombre de formes et de soumissions que vous prévoyez d'obtenir. Si vous avez beaucoup de deux, l'utilisation d'une collection / une soumission sera très difficile à fumer plus tard.
Honnêtement, j'utiliserais une seule collection, puis remplacer le champ
_id sur quelque chose qui peut raisonnablement être utilisé comme clé de démarrage. Il y a quelques astuces de fantaisie que vous pouvez jouer ici, mais cela dépasse la portée de cette petite rédaction.Résumé
fin de la journée, vous pouvez absolument utiliser mongodb pour ce problème, mais ce n'est pas une "gestion de la maison". Si vous n'êtes pas familier avec Mongodb, il s'agit certainement d'un «projet d'apprentissage» équitable, mais attendez-vous à frapper des barrages routiers autour d'interrogation et d'agrégation.
Merci pour vos conseils. J'ai essayé de construire un schéma de base de données que je crois résoudra mon problème en utilisant uniquement MySQL. L'esprit lui donne un look et me dise ce que vous pensez? Il est maintenant posté dans ma question sous 'Edit 2'
Un collègue d'une mine mène récemment un webinaire sur ce sujet, intitulé «Applications hybrides avec MongoDB et SGBDM». Vous pouvez voir ça ici: http://www.10gen.com/events/hybrid-applications
Des commentaires, il semble que vous ayez déjà décidé d'aller la voie de la SGBDM, mais j'espère que cela peut vous donner des idées pour un futur projet ou être bénéfique pour la lecture de ce fil.
bonne chance avec votre application!
Merci @marc, l'exemple du webinaire d'utiliser de la doctine pour garder les choses droites lorsque la jumelage mysql / sql w / mongodub / nosql semble très bonne. Je cherche toujours ceci.
Avec le schéma que vous avez fourni, à quoi ressemble une requête pour faire une recherche simple sur l'une des colonnes personnalisées?