2009-02-02 13 views
5

Estoy almacenando una cadena JSON en la base de datos que representa un conjunto de propiedades. En el código subyacente, lo exporto y lo uso para alguna lógica personalizada. Esencialmente, lo estoy usando solo como un mecanismo de almacenamiento. Entiendo que XML es más adecuado para esto, pero he leído que JSON es más rápido y preferido.¿JSON se usa solo para JavaScript?

¿Es una buena práctica usar JSON si la intención no es utilizar la cadena en el lado del cliente?

Respuesta

8

JSON es una forma perfectamente válida de almacenar datos estructurados y más simple y más conciso que XML. No creo que sea una "mala práctica" usarlo por el mismo motivo por el que alguien usaría XML, siempre y cuando usted entienda y esté de acuerdo con sus limitaciones.

2

Sí, creo que JSON es genial. Es un estándar abierto y puede ser utilizado por cualquier lenguaje de programación. La mayoría de los lenguajes de programación tienen librerías para analizar y codificar JSON también.

5

No puedo decir si es una buena práctica, pero me parece extraño. Tener campos XML en su base de datos SQL es al menos consultable (SQL Server 2000 o posterior, MySQL y otros) pero la mayoría de las veces es el último recurso para los metadatos.

JSON es por lo general la portadora entre JavaScript y su parte final, no el almacenamiento en sí a menos que tenga un extremo posterior JSON document orientated database como CouchDB o SOLR como JSON se presta perfectamente para almacenar documentos.

No estoy de acuerdo No estoy de acuerdo con el uso de JSON como serializador de datos simple (es decir, no serializando referencias) sobre XML, pero no voy a entrar en una queja JSON vs XML por el simple hecho de hacerlo:)

Si no está utilizando JSON para su portabilidad entre 2 idiomas, y está seguro de que nunca consultará los datos de SQL, estará mejor con la serialización predeterminada de .NET.

0

JSON es más corto, por lo que utilizará menos espacio en su base de datos. Probablemente lo usaría en lugar de XML o escribiría mi propio formato.

Por otro lado, la búsqueda de coincidencias apestará; tendrá que usar "where json like '% somevalue%'", que será muy lento. Esta es la misma limitación con cualquier otra estrategia de almacenamiento de texto (xml incluido).

2

JSON es solo un lenguaje de marcado como XML, y debido a su especificación más restrictiva es más pequeño en tamaño y más rápido de generar y analizar. Por lo tanto, desde ese aspecto, es perfectamente aceptable utilizarlo en la base de datos si necesita un marcado estructurado ad-hoc (y está absolutamente seguro de que no es posible usar tablas y/o la mejor solución).

Sin embargo, no dice qué base de datos está utilizando. Si es SQL Server 2005 o posterior, la base de datos en sí tiene amplias capacidades cuando se trata de XML, incluido un tipo de datos XML, soporte XQuery y la capacidad de optimizar expresiones XQuery como parte de un plan de ejecución. Entonces, si este es el caso, estaría mucho más inclinado a usar XML y aprovechar las instalaciones de la base de datos.

4

No es el único que utiliza JSON para el almacenamiento de datos. CouchDB es una base de datos orientada a documentos que utiliza JSON para almacenar información. Inicialmente almacenaron esa información como XML, luego cambiaron a JSON. La consulta se realiza a través de un buen HTTP antiguo.

Por cierto, CouchDB recibido alguna atención últimamente y está respaldado por IBM y la Apache Software Foundation. Está escrito en Erlang y promete mucho (en mi humilde opinión).

1

Recuerde que JSON tiene todos los mismos problemas que XML tiene como almacén de datos de fondo; es decir, de ninguna manera reemplaza una base de datos relacional o incluso un formato binario de tamaño fijo. Si tiene millones de filas y necesita acceso aleatorio, se encontrará con los mismos problemas de rendimiento fundamentales con JSON que con XML. Dudo que tenga la intención de usarlo para este tipo de escenario de almacén de datos, pero nunca se sabe ... se han intentado cosas extrañas :)

-1

No debe usar JSON o XML para almacenar datos en un entorno relacional base de datos. JSON y XML son formatos de serialización que son útiles para almacenar datos en archivos o enviarlos por cable.

Si desea almacenar un conjunto de propiedades, simplemente cree una tabla para ello, con cada fila siendo una propiedad. De esa manera puede consultar los datos utilizando SQL ordinario.

+0

Lo guardo en una base de datos cuando sé que no será necesario separar el objeto para consultarlo. – Nosredna

+0

Exactamente: aunque no es óptimo, hay casos en los que desea almacenar datos estructurados que son "atómicos", es decir, que solo se utilizan como entidad, no por piezas. Si es así, diseccionarlo en filas y columnas es solo por encima. Y aunque almacenar estos en RDBMS en sí mismo es un desperdicio (las tiendas clave/valor serían mejores), puede ser una opción decente si todo lo que tiene es un DB. – StaxMan

Cuestiones relacionadas