IBM pureXML, um banco de dados XML proprietário construído em um mecanismo relacional (projetado para trocadilhos) que oferece linguagens de consulta relacionais ( SQL / XML ) e não estruturadas ( XQuery ) e MarkLogic, um banco de dados construído a partir de zero com base em um novo paradigma de banco de dados (chame-o de NoSQL se quiser) que entende dados não estruturados e oferece linguagem de consulta não estruturada ( XQuery ).
Outra informação importante é a nova tendência entre os provedores de banco de dados NoSQL para implementação de SQL (ou interfaces semelhantes a SQL). Um exemplo é a recente promoção do Cassandra com CQL ou interfaces SQL ainda mais maduras baseadas em Hadoop.
Quando dois mundos colidem
NoSQL sobre Sem SQL . Para mim, isso significa mudar a ênfase para alternativas de banco de dados não relacionais, que podem até explorar diferentes interfaces para o banco de dados (e não se importam com o politicamente correto). Isto é uma coisa boa! Admitindo cegamente a fraqueza do SQL para os negócios? Bem, mesmo que o SQL seja a escolha certa para o seu produto, você ainda precisa pensar nas consequências e garantir que as coisas estejam bem alinhadas entre os dois mundos. Em outras palavras, significa remover a parte “cega” e reduzir “coxo” a um mínimo aceitável para seus desenvolvedores.
Modelo de dados
No relacional você tem:
RowSet -> SQL -> RowSet
RowSet é algo assim:
RowSet -> Item+
Item -> INT | VARCHAR n | ...
Vou falar sobre o modelo de dados XPath:
XDM -> XPath/XQuery -> XDM
E o XDM é algo assim:
XDM -> Item+
Item -> AtomicType | Tree
AtomicType -> integer | string | ...
...
(Ambos são simplificados, mas servem a um propósito).
Uma característica distintiva do modelo de dados para o documento é que as árvores não são planas:
{
"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."
}
}
Assim, há muitas interpretações do que isso pode significar:
SELECT comments from PERSON where handle = "dscape"
A qual elemento de “comentário” a solicitação se refere? Se você observar SQL/XML, sua consulta ficará assim:
SELECT XMLQuery('$person/comments')
FROM PERSON
WHERE XMLExists('$person/person/handle')
Isso leva a esta conclusão óbvia:as árvores precisam de uma maneira de navegar. Em XML é XPath, em JSON pode ser JSONSelect, talvez outra coisa. Mas você ainda precisa do método de navegação padrão em primeiro lugar.
O que torna essa tarefa ainda mais interessante é o controle de versão e o desenvolvimento de circuitos. Apesar de isso ter sido ignorado há tempos no mundo relacional (com sérias consequências para os negócios devido ao tempo de inatividade nesses momentos engraçados de mudanças de mesa). , isso não deve ser ignorado para documentos. Pense no Microsoft Word – quantas versões diferentes de documentos eles suportam? Word 2003, 2005, etc.
Sem esquema, flexibilidade, não estruturado:escolha sua palavra, mas todos estão sujeitos à rápida evolução dos formatos de dados. Nesta consulta, assumimos que o descritor é uma criança humana e que os comentários de que sou um idiota são descendentes diretos da árvore. Isso certamente vai mudar. E o SQL não suporta o versionamento de documentos, então você terá que estendê-lo para que funcione.
A linguagem de consulta real para dados não estruturados deve levar em consideração a versão. Em XQuery podemos expressar esta consulta como algo assim:
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
Frankenqueries, por exemplo
Alguém me mencionou uma vez (falando sobre SQL / XML) como essas Frankenqueries. O termo ficou na minha cabeça até agora. Vamos olhar um pouco mais longe nesta analogia e procurar lugares onde peças orgânicas e parafusos se juntam.
Vamos apresentar duas listas de compras, uma para Joe e outra para Mary.
marys-shopping.json
{"fruit": {
"apples": 2
}, "apples": 5 }
joes-shopping.json
{"fruit": {
"apples": 6,
"oranges": 1
} }
Agora com minha extensão SQL/JSON “imaginária”, eu faço:
SELECT apples
FROM LISTS
O que retorna? Lembre-se, RowSet entra, RowSet sai?
2, 5
---
6
Assim, mesmo se você solicitar explicitamente uma lista de números de maçã, obterá dois conjuntos de linhas em vez de três, e um dos conjuntos de linhas terá uma lista de números. Se você optar por retornar três coisas, você obterá dois conjuntos de RowSet e três conjuntos de RowSet. Não sou matemático, mas isso não soa bem.
Mais uma vez, não é um problema se você usar algo que possa lidar com informações não estruturadas. Você não tem esse problema em javascript e, claro, não será em XQuery. Tanto em javascript quanto em XQuery é tudo orgânico.
Conclusão:linguagens impressionantes para dados não estruturados, unicórnios e pó mágico!
Embora XQuery seja uma linguagem excelente para informações não estruturadas, meu ponto de vista aqui não protege seu uso. O ponto que estou tentando enfatizar é a necessidade de uma linguagem real para dados não estruturados, não importa como você (leia:desenvolvedores) a escolha.
Mas peço a vocês (desenvolvedores) que não retirem o “SQL coxo”. Ela se foi e você tem um novo encontro quente chamado NoSQL. Basta dar-lhe algum tempo e ele vai crescer em você. Também é muito divertido escrever código JavaScript que funcione em bancos de dados:não deixe que eles o tirem de você.
O SQL para dados não estruturados falhará. Então, o PL-SQL para dados não estruturados falhará. Portanto, se o fornecedor insistir no que você precisa, não aceite nada menos que uma linguagem de programação completa:você pode escrever seu aplicativo completo em javascript e salvá-lo no CouchApp, ou pode escrever seu aplicativo completo em XQuery e salvá-lo no MarkLogic . E assim deve ser!
Aqui está uma lista de verificação do que procurar na linguagem de consulta para informações não estruturadas:
- O idioma da navegação
- Modelo de dados
- Expressões normais
- Lambda
- Funções de alta ordem
- Fragrância funcional
- Bom processamento de linha
- Módulos para que você possa criar suas próprias bibliotecas
- O servidor de aplicativos está ciente:possui funções que servem REST
Você pode ignorar este conselho, mas no final, você pode se sentir frustrado com o desenvolvedor do Silverlight. E nós, os caras que gostam de inovar em banco de dados, ficaremos desapontados que os desenvolvedores decidiram voltar!
