Estaba hurgando en la base de datos AdventureWorks hoy y noté que varias tablas ( HumanResources.JobCandidatey, Sales.Individualpor ejemplo) tienen una columna que almacena datos xml.
Lo que quiero saber es, ¿cuál es la ventaja de almacenar básicamente el valor de una fila de la tabla de la base de datos en la columna de otra tabla? ¿Esto no dificulta la consulta de esta información? ¿O se supone que los datos no tendrán que consultarse y solo deberán almacenarse?
Respuestas:
Debido a que no todos los datos deben almacenarse relacionalmente, escribir código para procesar los datos que ha pasado como XML para el almacenamiento relacional consume mucho tiempo (y es muy tedioso). Esto es particularmente cierto cuando una gran cantidad de datos XML proviene de sistemas que arrojan grandes respuestas genéricas.
Con frecuencia he visto situaciones en las que se recibe un mensaje de otro sistema y no nos importa el 98% de lo que contiene. Así que lo analizamos para dividir el 2% que nos importa, lo almacenamos relacionalmente y luego almacenamos el mensaje completo en caso de que necesitemos algo del 98% restante más adelante.
Y SQL Server le brinda algunas herramientas y sintaxis correctas para trabajar con XML en T-SQL, por lo que no es como si estuviera totalmente fuera del alcance práctico para consultas ad-hoc de la forma en que podría estar si estuviera almacenando, digamos, el contenido de un CSV.
Y eso excluye la posibilidad de que lo que realmente desea almacenar es XML (por ejemplo, para fines de soporte y depuración) ...
Si el formato de datos es volátil y está sujeto a posibles cambios, es posible que desee agruparlo como XML y colocarlo en la base de datos de esta forma para evitar futuros cambios en el esquema de la base de datos.
En la misma tangente, si algún sistema externo proporciona los datos y los consume de nuevo, y no pueden proporcionarle un formato permanente, eso es lo que haría.
¿Esto no dificulta la consulta de esta información?
SQL Server puede consultar campos y variables XML. No necesariamente difícil, pero más trabajo, sí. Pero factible.
En mi experiencia, los datos XML generalmente se almacenan y rara vez se consultan, pero a menudo se extraen cuando es necesario, generalmente cuando algún otro sistema necesita una representación XML de algunos datos que pueden ser difíciles o imposibles de generar sobre la marcha a partir de datos relacionales. Los datos XML pueden estar rellenados previamente por algún otro proceso.
Si puede imaginar almacenar sus datos en una secuencia binaria en un blob, entonces me imagino que puede imaginar almacenar sus datos en un formato xml en un blob.
Por supuesto, es mejor dejar muchas cosas en la imaginación del imaginador.
Digamos, registros médicos electrónicos, por ejemplo:
Ya que lo más probable es que almacene el ASCII HL7 V2.x en un campo en una base de datos. Probablemente sea apto para almacenar HL7 V3.0 en un campo en una base de datos.
Entonces la ventaja es la conveniencia.
Actualmente estoy trabajando en un proyecto que hace esto. Tenemos datos que necesitan ser procesados varias veces, almacenados relacionalmente. Sin embargo, el procesamiento se realiza en Java, y es más fácil trabajar con XML allí. Entonces, hacemos un pase de una sola vez a través de los datos relacionales y los almacenamos como XML en una tabla. Luego, podemos procesar esos datos en Java con una consulta que no se une, en lugar de recuperar datos cada vez, y procesar los mismos datos una y otra vez al contenido de nuestro corazón. Es mucho más simple y más eficiente.
Un buen ejemplo de almacenamiento de XML es cuando desea conservar los estados de la IU en la base de datos. El estado de todas las vistas de la aplicación se serializa y almacena en la base de datos y no es necesario consultar el XML. Por estado de interfaz de usuario quiero decir, orden de vista, tamaño de las ventanas, etc.
A menudo obtiene datos mixtos que son XML y relacionales. (Un buen ejemplo de esto es un almacén de documentos donde cada documento puede tener campos de metadatos como título, fecha de creación, propietario, etc.)
En este punto, debe elegir entre tres opciones:
La opción 3 es probablemente la más limpia, pero también la más costosa y la más difícil de implementar, además de que no necesariamente desea transacciones distribuidas en un sistema no muy grande. La opción 2 no es muy buena ya que las bases de datos XML nativas suelen ser extremadamente pobres en el manejo de datos relacionales (que es más probable que use en las búsquedas) y la tecnología es en general menos madura que la base de datos relacional.
Eso te deja con la opción 1, ya que ciertamente no es la mejor solución, pero quizás la menos mala.
En mi experiencia, el uso de XML en una base de datos termina siendo así porque así es como lo almacena la fuente de los datos, o lo está agregando a una base de datos existente para extender la funcionalidad de una manera que no requerirá mucha programación de base de datos para soportar .
Si va a buscar los nuevos datos con frecuencia, puede tener sentido dividir el XML en sus componentes. De lo contrario, puede ser una forma útil de guardar datos modificados con poca frecuencia.
Espero que esto ayude, Jeff
Los almacenes de datos orientados a documentos (también conocidos como NoSql) son muy populares en estos días:
http://en.wikipedia.org/wiki/Document-oriented_database
No hay ninguna razón por la que no pueda emplear un esquema orientado a documentos en una base de datos relacional. Es posible que no obtenga los mismos beneficios en comparación con algo como Mongo, pero tampoco tendrá los inconvenientes.
Durante mucho tiempo, si quería utilizar el almacenamiento orientado a documentos, su única opción era insertar datos estructurados (como XML) en una gran columna. Las bases de datos relacionales han estado agregando características como indexación y coincidencia para soportar eso.
Contrasta eso con Mongo, donde lo único en la base de datos son los documentos. Pero ese es otro tema.
EDITAR: la idea central de la orientación a documentos es: extraer los datos, manipularlos y devolverlos en su totalidad. A veces, como cuando estás transmitiendo el documento al cliente, solo quieres enviarlo todo como una gota y dejar que se encarguen de ello. El beneficio (y el inconveniente) es la flexibilidad. La validación y corrección del documento se realiza fuera de la base de datos.
EDITAR EDITAR: Otro contraste. Imagine guardar imágenes JPG o documentos de Word en una columna de base de datos.
¿Cuáles son las ventajas de almacenar un árbol (XML) en una lista de tuplas (una tabla de base de datos)?
No hay ninguna razón por la cual el XML no debe ser consultable desde su DBMS usando, por ejemplo, XPath o SPARQL.
A mi entender, son simplemente dos estructuras de datos diferentes. Y no hay ninguna razón por la que no deberían integrarse entre sí.
Puede buscar los motivos por los que se agregó el tipo de datos JSON en PostgreSQL. Creo que se aplican muchos de los mismos argumentos. Excepto que con XML / XSD, es posible una validación aún mayor.
Bueno, XML (o JSON) es bastante bueno para almacenar metadatos con jerarquía. Cuales son las alternativas? ¿Una tabla de metadatos con refid / key / value / depth tal vez? Es un poco engorroso (pero probablemente sea mejor para consultar si necesita hacerlo). Almacenar algunos datos xml sobre un documento (una fila en una tabla de documentos) es bastante conveniente cuando desea almacenar algunas informaciones jerárquicas sin tener que depender de una tabla externa o tener que agregar 1 columna por "tipo" de información.
Yo diría que fue una mala práctica, ya que está obstruyendo el almacenamiento eficiente de otro modo con etiquetas ineficientes que no necesitan estar allí si se esfuerza por analizar la información. XML tiene una sobrecarga de almacenamiento horrible en comparación con los datos que describe, ya que necesita una etiqueta para cada columna para cada fila. En comparación, los datos analizados y almacenados en formato relacional tienen su nombre de columna almacenado UNA VEZ. Por una docena de filas en un desarrollador. caja, gran cosa, pero he visto a los desarrolladores asumir que esto es escalable a millones de filas. Esto puede representar cientos de GB de sobrecarga para unas pocas docenas de GB de datos, lo que crea desafíos operativos. Básicamente estás renunciando a la responsabilidad de ti mismo y presionando a las personas que tienen que apoyar la basura que has escrito.
Entonces, ¿por qué no almacenarlo LEJOS de los datos operativos, en su propia base de datos? O como se pretendía, ¿en archivos planos? Probablemente nunca se volverá a ver, así que ¿por qué no eliminarlo de afectar el rendimiento de un sistema operativo? Recuerde que XML SÓLO está allí para proporcionar una descripción del esquema de datos que de otro modo no sería aparente debido a las diferencias de protocolo de almacenamiento entre sistemas. Ese es todo su punto, no hay nada inteligente al respecto. Almacenar 10 veces la cantidad de gastos generales para una cantidad dada de datos solo dice que eres un desarrollador descuidado que no ha pensado bien y no puede ser procesado para procesar los datos que estás consumiendo en un formato sensible, eficiente y rápido de consulta. Deje de empujar su esfuerzo al soporte operativo y PIENSE en cómo puede manejar mejor los datos después de ' Lo he recibido sería mi llamada. No hay defensa para almacenar datos como XML después de recibirlos, ya que cumplió su propósito.