IBM pureXML, una base de datos XML patentada construida sobre un mecanismo relacional (diseñado para juegos de palabras) que ofrece lenguajes de consulta tanto relacionales ( SQL / XML ) como no estructurados ( XQuery ), y MarkLogic, una base de datos construida a partir de cero sobre la base de un nuevo paradigma de base de datos (llámelo NoSQL si lo desea) que comprende datos no estructurados y ofrece un lenguaje de consulta no estructurado ( XQuery ).
Otra información importante es la nueva tendencia entre los proveedores de bases de datos NoSQL para implementar SQL (o interfaces similares a SQL). Un ejemplo es la reciente promoción de Cassandra con CQL o incluso interfaces SQL más maduras basadas en Hadoop.
Cuando dos mundos chocan
NoSQL acerca de No SQL. Para mí, esto significa cambiar el énfasis a alternativas de bases de datos no relacionales, que pueden incluso explorar diferentes interfaces a la base de datos (y no preocuparse por la corrección política). ¡Ésto es una cosa buena! ¿Admitir ciegamente la debilidad de SQL para los negocios? Bueno, incluso si SQL es la opción correcta para su producto, aún debe pensar en las consecuencias y asegurarse de que las cosas estén bien alineadas entre los dos mundos. En otras palabras, significa eliminar la parte "ciega" y reducir "lame" a un mínimo aceptable para sus desarrolladores.
Modelo de datos
En relacional tienes:
RowSet -> SQL -> RowSet
RowSet es algo así:
RowSet -> Item+
Item -> INT | VARCHAR n | ...
Te contaré sobre el modelo de datos XPath:
XDM -> XPath/XQuery -> XDM
Y XDM es algo así:
XDM -> Item+
Item -> AtomicType | Tree
AtomicType -> integer | string | ...
...
(Ambos están simplificados, pero tienen un propósito).
Una característica distintiva del modelo de datos del documento es que los árboles no son planos:
{
"namespace": "person-2.0",
"comments": "This guy asked me for a dinosaur sticker. What a nutter!",
"person": {
"handle": "dscape",
"comments": "Please do not send unsolicited mail."
}
}
Por lo tanto, hay muchas interpretaciones de lo que esto puede significar:
SELECT comments from PERSON where handle = "dscape"
¿A qué elemento de “comentario” se refiere la solicitud? Si observa SQL/XML, su consulta se verá así:
SELECT XMLQuery('$person/comments')
FROM PERSON
WHERE XMLExists('$person/person/handle')
Esto lleva a esta conclusión obvia:los árboles necesitan una forma de navegar. En XML es XPath, en JSON podría ser JSONSelect, tal vez algo más. Pero aún necesita el método de navegación estándar en primer lugar.
Lo que hace que esta tarea sea aún más interesante es el control de versiones y el desarrollo de circuitos. A pesar de que esto ha sido ignorado durante siglos en el mundo relacional (con graves consecuencias para los negocios debido al tiempo muerto en estos divertidos momentos de cambios de mesa). , de hecho, esto no debe ignorarse para los documentos. Piense en Microsoft Word:¿cuántas versiones diferentes de documentos admiten? Word 2003, 2005, etc.
Sin esquema, flexibilidad, sin estructura:elige tu palabra, pero todos están sujetos a la rápida evolución de los formatos de datos. En esta consulta, asumimos que el descriptor es un niño humano y que los comentarios de que soy un idiota son descendientes directos del árbol. Esto sin duda cambiará. Y SQL no admite el control de versiones de documentos, por lo que tendrá que ampliarlo para que funcione.
El lenguaje de consulta real para datos no estructurados debe tener en cuenta la versión. En XQuery podemos expresar esta consulta como algo así:
declare namespace p = "person-2.0" ;
for $person in collection('person')
let $comments-on-person := $person/p:comments
where $person/p:handle = "dscape"
return $comments-on-person
Frankenconsultas, por ejemplo
Alguien me mencionó una vez (hablando de SQL/XML) como estas Frankenqueries. El término se me ha quedado grabado en la cabeza hasta ahora. Profundicemos un poco más en esta analogía y busquemos los lugares donde se juntan las partes orgánicas y los pernos.
Presentemos dos listas de compras, una para Joe y otra para Mary.
marys-shopping.json
{"fruit": {
"apples": 2
}, "apples": 5 }
joes-shopping.json
{"fruit": {
"apples": 6,
"oranges": 1
} }
Ahora, con mi extensión SQL/JSON "imaginaria", hago:
SELECT apples
FROM LISTS
¿Qué devuelve? ¿Recuerdas que RowSet entra y RowSet sale?
2, 5
---
6
Por lo tanto, incluso si solicita explícitamente una lista de números de manzana, obtiene dos conjuntos de filas en lugar de tres, y uno de los conjuntos de filas tendrá una lista de números. Si elige devolver tres cosas en su lugar, obtendrá dos conjuntos de RowSet y tres conjuntos de RowSet. No soy matemático, pero eso no suena bien.
Una vez más, no es un problema si usa algo que pueda tratar con información no estructurada. No tiene este problema en javascript y, por supuesto, no lo estará en XQuery. Tanto en javascript como en XQuery todo es orgánico.
Conclusión:¡lenguajes asombrosos para datos no estructurados, unicornios y polvo de hadas!
Aunque XQuery es un lenguaje excelente para información no estructurada, mi punto de vista aquí no protege su uso. El punto que estoy tratando de enfatizar es la necesidad de un lenguaje real para datos no estructurados, sin importar cómo lo elijas (léase:desarrolladores).
Pero les pido a ustedes (los desarrolladores) que no recuperen el "SQL cojo". Ella se fue y tú tienes una nueva cita interesante llamada NoSQL. Solo dale un poco de tiempo y crecerá en ti. También es muy divertido escribir código JavaScript que funcione en bases de datos:no dejes que te lo quiten.
SQL para datos no estructurados fallará. Entonces fallará PL-SQL para datos no estructurados. Entonces, si el proveedor insiste en lo que necesita, no acepte nada menos que un lenguaje de programación completo:puede escribir su aplicación completa en javascript y guardarla en CouchApp, o puede escribir su aplicación completa en XQuery y guardarla en MarkLogic. . ¡Y así debería ser!
Aquí hay una lista de verificación de lo que debe buscar en el lenguaje de consulta para obtener información no estructurada:
- El idioma de navegación
- Modelo de datos
- Expresiones normales
- Lambda
- Funciones de orden superior
- Fragancia funcional
- Buen procesamiento de línea
- Módulos para que puedas crear tus propias bibliotecas
- El servidor de aplicaciones es consciente:tiene funciones que sirven REST
Puede ignorar este consejo, pero al final, puede sentirse frustrado con el desarrollador de Silverlight. ¡Y a nosotros, a los que nos gusta innovar en bases de datos, nos decepcionará que los desarrolladores decidieran regresar!
