mysql - fields - mongodb tutorial español
Asesoramiento sobre la mezcla de MongoDB con MySQL para una aplicación web (3)
Creo que está pasando por alto el hecho de que un RDBMS permitirá cosas como EAV (Entity-Attribute-Value, que es horrible si la usa en exceso, pero puede ser excelente con moderación) o unir tablas, para construir múltiples relaciones ordenadas desde un único forma a varios elementos de forma.
No estoy sugiriendo que un RDBMS sea perfecto para todo, o incluso su situación, pero sé que tuve que construir sistemas similares y nunca tuve que ir a ningún SQL para soportarlos de una manera razonable.
Editar: más al punto ... el almacenamiento de los valores de campo reales le da una relación más de los elementos de formulario originales, pero si su UI mantiene las cosas consistentes, puede hacerlo de forma genérica. Yo diría que profundizar más en las soluciones que SQL no permiten que los tipos particulares de consultas basadas en valores que necesita puedan arrojar más luz sobre sus opciones.
Tengo una aplicación web que usa una base de datos relacional (MySQL). Estamos agregando una nueva característica que permitirá a ciertos usuarios construir dinámicamente ''formularios'' a partir de un grupo de elementos de formulario opcionales y distribuir estos formularios para completarlos / enviarlos a otros usuarios.
El problema radica en almacenar los envíos de formularios completados. Cada formulario puede y variará en el número y la combinación de elementos del formulario, y con una base de datos relacional, mis opciones están limitadas a crear dinámicamente una nueva tabla para guardar los envíos de cada formulario (parece una mala ruta para bajar) o almacenar cada uno de los formularios enviados como JSON en una columna de TEXTO (perdiendo todas las habilidades de consulta útiles de RDBMS)
Nunca antes había usado MongoDB en un proyecto de producción, pero creo que podría ser una buena idea usar mi base de datos relacional de MySQL para almacenar todos los formularios creados por ciertos usuarios de mi aplicación, y luego almacenar todas las presentaciones en MongoDB con cada documento que hace referencia al UUID del formulario en MySQL.
La primera desventaja que se me ocurre con este enfoque es que no hay integridad referencial entre los envíos de formularios y los formularios ubicados en MySQL. Si elimino un formulario en MySQL, todos los envíos de formularios deberán borrarse manualmente (si deseo replicar el efecto ''Cascade'')
¿Guardaría todos mis envíos de formularios para todos mis formularios en una única colección MongoDB como documentos individuales? Cualquier consejo es muy apreciado. :)
EDITAR 1 Basado en la documentación aquí: http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections
Ahora estoy considerando crear una nueva colección para albergar todas las presentaciones de cada tipo de formulario único.
EDIT 2
Después de una cuidadosa consideración y el consejo de otros, he decidido abandonar mi enfoque de doble base de datos para resolver este problema a favor de un esquema de base de datos relacionales que creo resuelve el problema de crear formularios dinámicos y guardar los formularios de forma tal forma en que son fácilmente consultables para informes complejos.
Esencialmente, cada registro en ''formularios'' representa una forma única que fue construida por un usuario. ''forms_fields'' tiene una clave externa que hace referencia al formulario y un tipo de enumeración con las siguientes opciones: 1. casilla de verificación 2. campo de texto 3. área de texto 4. seleccionar 5. selección múltiple 6. fecha
''forms_fields_options'' contiene todas las ''opciones'' que tendría un campo de selección. Con estas tres tablas, los usuarios pueden crear formularios personalizados.
Cuando otro usuario rellena y envía el formulario, se crea un registro en forms_submissions. Para cada campo, se creará un registro correspondiente en ''forms_submissions_fields'' que hace referencia al envío del formulario y forms_fields_id. La tabla final, ''forms_submissions_options_multiselect'' es esencialmente una tabla de unión para indicar qué opciones de un campo de formulario de selección múltiple el usuario seleccionó.
Esto definitivamente se puede hacer en SQL usando EAV . Entonces NoSQL definitivamente no es requerido.
El uso de una herramienta como MongoDB podría ser una buena opción para los resultados flexibles que desea guardar, sin embargo, hay algunas compensaciones aquí, pero pueden no ser exactamente lo que está esperando.
... almacenando cada uno de los formularios enviados como JSON en una columna de TEXTO ( perdiendo todas las habilidades de consulta útiles de RDBMS )
¿Cuántas presentaciones de formularios planea tener? ¿Qué tipo de consultas estás planeando hacer?
Mi experiencia con MongoDB es que funciona muy mal cuando consultas sobre datos que no están indexados. Además, la agregación generalmente se realiza en lotes usando Map / Reduce ( o el nuevo Framework de Agregación ).
Si comparas la complejidad de hacer roll-ups o la eficiencia de hacer consultas, no está claro que MongoDB sea significativamente mejor aquí que EAV.
Si elimino un formulario en MySQL, todos los envíos de formularios deberán eliminarse manualmente
Curiosamente, rara vez he visto esto como un problema, ya que probablemente nunca elimine el formulario en SQL. es probable que hagas una eliminación lógica y nunca elimines nada. Entonces este es probablemente un punto discutible.
¿Guardaría todos mis envíos de formularios para todos mis formularios en una única colección MongoDB como documentos individuales?
De nuevo, depende de la cantidad de formularios y envíos que planea obtener. Si tiene muchos de ambos, entonces usar una colección / envío será muy difícil de fragmentar más tarde.
Honestamente, usaría una única colección y luego anularía el campo _id a algo que pueda usarse razonablemente como una clave de fragmento. Hay algunos trucos de fantasía que puedes jugar aquí, pero eso está más allá del alcance de este pequeño artículo.
Resumen
Al final del día, definitivamente puede usar MongoDB para este problema, pero no es un "home run". Si no está familiarizado con MongoDB, este es definitivamente un "proyecto de aprendizaje" justo, pero espere encontrar algunos obstáculos en las consultas y la agregación.
Un colega mío dirigió recientemente un seminario web sobre este tema, titulado "Aplicaciones híbridas con MongoDB y RDBMS". Puede verlo aquí: http://www.10gen.com/events/hybrid-applications
A partir de los comentarios, parece que ya ha decidido ir a la ruta RDBMS, pero con suerte esto le puede dar algunas ideas para un proyecto futuro, o puede ser beneficioso para alguien más que lea este hilo.
¡Buena suerte con tu aplicación!