Estoy desarrollando un generador de formularios, y me pregunto si sería malo mojo almacenar JSON en una base de datos SQL.¿Está almacenando JSON en una base de datos msSQL?
quiero mantener mi base de datos & tablas sencilla, así que iba a tener
`pKey, formTitle, formJSON`
sobre una mesa, y luego almacenar
{["firstName":{"required":"true","type":"text"},"lastName":{"required":"true","type":"text"}}
en formJSON.
Se agradece cualquier entrada.
Utilizo mucho JSON en mi CMS (que aloja alrededor de 110 sitios) y encuentro que la velocidad de acceso a los datos es muy rápida. Me sorprendió que no hubiera más degradación de velocidad. Cada objeto en el CMS (Página, Diseño, Lista, Tema, etc.) tiene una columna NVARCHAR (MAX) llamada JSONConfiguration. Mi herramienta ORM sabe buscar esa columna y reconstituirla como un objeto si es necesario. O, dependiendo de la situación, solo lo pasaré al cliente para que jQuery o Ext JS procesen.
En cuanto a la legibilidad/mantenimiento de mi código, puede decir que ha mejorado porque ahora tengo clases que representan una gran cantidad de objetos JSON almacenados en la base de datos.
Utilicé JSON.net para todas las serializaciones/deserialización. http://james.newtonking.com/default.aspx
También uso una única consulta para devolver meta-JSON con los datos reales. Como en el caso de Ext JS, tengo consultas que devuelven tanto la estructura del objeto Ext JS como los datos que el objeto necesitará. Esto corta una publicación posterior/SQL de ida y vuelta.
También me sorprendió lo rápido que fue el código para analizar una lista de objetos JSON y asignarlos a un objeto DataTable que luego entregué a un GridView.
El único inconveniente que he visto al utilizar JSON es la indexación. Si tiene una propiedad del JSON que necesita buscar, entonces debe almacenarla como una columna separada.
Existen bases de datos JSON que pueden satisfacer mejor sus necesidades: CouchDB, MongoDB y Cassandra.
Será más lento que tener el formulario definido en el código, pero una consulta adicional no debería causarle mucho daño. (Pero no deje 1 de consultas extra se convierten en 10 consultas adicionales!)
Editar: Si está seleccionando la fila por formTitle en lugar de pKey (yo, porque entonces su código será más legible), poner un índice en formTitle
No lo recomendaría.
Si alguna vez quiere hacer algún informe o consulta basado en estos valores en el futuro, va a hacer su vida mucho más difícil que tener algunas tablas/columnas adicionales.
¿Por qué evitas hacer nuevas tablas? Digo si su aplicación requiere que continúen y los agreguen ... Además, si alguien tiene que pasar por su código/db más tarde, probablemente sea más difícil para ellos descubrir qué estaba pasando (dependiendo de qué tipo de documentación que tiene).
Una forma brillante de crear una base de datos de objetos desde el servidor sql.Hago esto para todos los objetos de configuración y todo lo demás que no necesita ninguna consulta específica. extendiendo su objeto - fácil, simplemente cree una nueva propiedad en su clase e inicie con el valor predeterminado. ¿Ya no necesitas una propiedad? Solo elimínalo en la clase. Fácil despliegue, fácil actualización. No es adecuado para todos los objetos, pero si extrae algún accesorio, debe indexarlo, seguir utilizándolo. Una forma muy moderna de usar el servidor sql.
Me he encontrado con muchas ocasiones en las que busco una solución y encuentro mi camino hasta aquí. En la búsqueda de la solución, a veces encuentro una mejor respuesta en otro lugar y quizás con una tecnología más nueva que la que se respondió en ese momento. No es solo para responder SU pregunta, sino para todos los que se encuentren en la misma situación que ustedes en el futuro. Y al igual que KOPEHb, seré lo suficientemente cortés como para actualizar o incluso ofrecer mejores soluciones de las que fueron respondidas. – Levitikon
Debería poder usar SisoDb para esto. http://sisodb.com
¿Alguien tiene alguna opinión después de usar SisoDB? Parece prometedor, pero este tipo de biblioteca realmente puede fallar cuando se usa en la práctica ... –
Hola, soy parcial porque construyo SisoDB pero lo estamos usando en un producto comercial que se está desarrollando hoy. Se usa para mantener las readmodels en un entorno CQRS. – Daniel
Hemos utilizado una versión modificada de XML exactamente para el propósito que usted describe durante siete u ocho años y funciona muy bien. Las necesidades de formularios de nuestros clientes son tan diversas que nunca podríamos seguir el ritmo de un enfoque de tabla/columna. Estamos demasiado lejos en el camino de XML para cambiar muy fácilmente, pero creo que JSON funcionaría tan bien y tal vez evan mejor.
Informar no es un problema con un par de buenas funciones de análisis y desafiaría a cualquiera a encontrar una diferencia significativa en el rendimiento entre nuestros informes/análisis y una solución de tabla/columna para esta necesidad.
Creo que no es una idea óptima para almacenar datos de objetos en una cadena en SQL. Tienes que hacer la transformación fuera de SQL para analizarlo. Eso presenta un problema de rendimiento y se pierde la influencia del uso de la capacidad de análisis de datos nativos de SQL. Una mejor manera sería almacenar JSON como un tipo de datos XML en SQL. De esta forma, matas a dos pájaros de un tiro: no tienes que crear montones de tablas y aún obtener todos los beneficios de consultas nativas de SQL.
Pasamos mucho tiempo en los formularios personalizados, que por lo general contienen la misma información, la mayor parte de esa información se almacena en sólo 3-4 mesas diferentes. Entonces, si pudiera crear los formularios de forma programática y enviarlos a sus tablas apropiadas, ahorraría mucho tiempo de desarrollo en el futuro. – JKirchartz
Creo que en esa situación, probablemente todo salga bien. Al igual que Michael dice que solo será una consulta extra. Pensé que intentabas almacenar valores junto con la estructura del formulario. –