Usando XML como armazenamento de dados [fechado]

Eu estava pensando sobre o formato XML e a seguinte citação:

“XML não é um banco de dados. Nunca foi concebido para ser um banco de dados. Nunca será um banco de dados. Os bancos de dados relacionais são uma tecnologia comprovada com mais de 20 anos de experiência em implementação. São produtos sólidos, estáveis ​​e úteis. Eles não vão embora. XML é uma tecnologia muito útil para mover dados entre diferentes bancos de dados ou entre bancos de dados e outros programas. No entanto, ele próprio não é um banco de dados. Não use-o como um. ”- XML eficaz: 50 maneiras específicas de melhorar seu XML de Elliotte Rusty Harold (página 230, Parte 4, Item 41, 2º parágrafo)

Isso parece realmente enfatizar que o XML não deve ser usado para armazenamento de dados e deve ser usado apenas para interoperabilidade entre programas.

Pessoalmente, eu discordo e o app.configarquivo do .NET usado para armazenar as configurações de um programa é um exemplo de armazenamento de dados em um arquivo XML. No entanto, para bancos de dados em vez de configurações, etc, o XML não deve ser usado.

Para desenvolver meu argumento, usarei dois exemplos:
A) Dados sobre clientes com campos todos em um nível, ou seja, existem vários campos relacionados a um cliente sem filhos
B) Dados sobre a configuração de um aplicativo em que campos aninhados e propriedades fazem muito sentido

Portanto, minha pergunta é: essa declaração ainda é válida e agora é aceitável armazenar dados usando XML?

EDIT: Enviei um e-mail ao autor dessa citação para solicitar sua contribuição / contexto extra.

Esta citação não se refere ao uso de XML como formato de armazenamento em geral (para o qual é bom, dependendo dos requisitos), mas para armazenamento do tipo banco de dados .

Quando as pessoas falam sobre bancos de dados, geralmente significam sistemas de armazenamento que armazenam grandes quantidades de dados, geralmente na faixa de gigabytes ou terabytes. Um banco de dados é potencialmente muito maior que a quantidade de RAM disponível no servidor que o armazena. Como ninguém precisa de todos os dados de um banco de dados de uma só vez, os bancos de dados devem ser otimizados para recuperação rápida de subconjuntos seletivos de dados: é para isso que SELECTservem as declarações, e os bancos de dados relacionais e as soluções NoSQL otimizam seu formato de armazenamento interno rapidamente recuperação de tais subconjuntos.

XML, no entanto, realmente não se encaixa nesses requisitos. Devido à sua estrutura de marca aninhada, é impossível determinar onde um determinado valor é armazenado no arquivo (em termos de deslocamento de bytes em um arquivo) sem percorrer toda a árvore de documentos, pelo menos até a correspondência. Um banco de dados relacional tem índices, e procurar um valor em um índice, mesmo com uma implementação primitiva de pesquisa binária, é uma única pesquisa de O (log n) e, em seguida, obter os valores reais não passa de uma busca de arquivo (por exemplo, fseek(data_file_handle, row_index * row_size)), que é O (1). Em um arquivo XML, a maneira mais eficiente é executar um analisador SAX no seu documento, fazendo muitas leituras e pesquisas antes de você chegar aos dados reais; dificilmente você conseguirá isso melhor que O (n), a menos que use índices, mas precisará reconstruir o índice inteiro para cada inserção (veja abaixo).

A inserção é ainda pior. Os bancos de dados relacionais não garantem a ordem das linhas, o que significa que eles podem apenas acrescentar novas linhas ou substituir quaisquer linhas marcadas como 'excluídas'. Isso é extremamente rápido: o banco de dados pode manter apenas um conjunto de locais graváveis; obter uma entrada do pool é O (1), a menos que o pool esteja vazio; Na pior das hipóteses, o pool está vazio e uma nova página deve ser criada, mas também é O (1). Por outro lado, um banco de dados baseado em XML teria que mover tudo após o ponto de inserção para liberar espaço; isso é O (n). Quando os índices entram em jogo, as coisas se tornam ainda mais interessantes: índices típicos de bancos de dados relacionais podem ser atualizados com uma complexidade relativamente baixa, digamos O (log n); mas se você deseja indexar seus arquivos XML, todas as inserções potencialmente alteram o local em disco de todos os valores do documento, portanto, é necessárioreconstruir o índice inteiro . Isso também vale para atualizações, porque a atualização, digamos, do conteúdo de texto de um elemento, pode mudar seu tamanho, o que significa que o XML consecutivo precisa ser alterado. Um banco de dados relacional não precisa tocar no índice, se você atualizar uma coluna não indexada; um banco de dados XML precisaria reconstruir o índice inteiro para cada atualização que altera o tamanho do nó XML atualizado.

Essas são as desvantagens mais importantes, mas existem mais. O XML é muito detalhado, o que é bom para a comunicação servidor a servidor, porque adiciona segurança (o servidor de recebimento pode executar todos os tipos de verificações de integridade no XML e, se algo der errado na transferência, é improvável que o documento valide ) Para armazenamento em massa, no entanto, isso é impressionante: não é incomum ter 100% ou mais de sobrecarga para dados XML (não é incomum ver taxas de sobrecarga no intervalo de 1000% para coisas como mensagens SOAP), enquanto o armazenamento de banco de dados relacional típico os esquemas têm apenas uma sobrecarga constante para os metadados da tabela, mais um pouquinho por linha; a maior parte da sobrecarga nos bancos de dados relacionais vem de larguras fixas de colunas. Se você possui um terabyte de dados, uma sobrecarga de 500% é simplesmente inaceitável, por vários motivos.

XML é péssimo para armazenamento de dados. Primeiro, é muito detalhado. Os dados armazenados em um arquivo XML ocuparão muito mais espaço em disco do que os mesmos dados armazenados em qualquer sistema de banco de dados razoável. Em um registro XML, o nome de um campo específico será armazenado duas vezes, juntamente com a representação em seqüência dos dados. Então, por exemplo, para armazenar um único número inteiro em um campo chamado "foobar", você acaba com essa cadeia de 19 bytes:

<foobar>42</foobar>

Por outro lado, um banco de dados real armazenará isso como um único valor inteiro, ocupando 4 bytes. Se seu banco de dados for pequeno, isso não significa muito, mas se você tiver 10.000 registros, isso é um problema.

Segundo, um XML precisa ser analisado do texto toda vez que o arquivo é lido. Para o campo acima, um banco de dados real simplesmente lê os dados binários na memória a partir do deslocamento em que sabe que armazenou o campo "foobar". Se o arquivo é armazenado como XML, ele deve ler o campo "foobar", analisar o texto , determine qual campo é, analise a sequência "42" e converta-a no binário 42.

Portanto, as penalidades de desempenho pelo uso de XML são enormes. Os benefícios do XML são que ele é um pouco legível por humanos e permite fácil transferência de dados entre sistemas completamente separados. Nenhuma dessas vantagens se aplica a um banco de dados local.

A única exceção são os arquivos de configuração, que geralmente são pequenos e geralmente precisam ser editáveis ​​por humanos.

Um banco de dados XML absolutamente será maior e mais lento que qualquer sistema SQL razoável. A menos que você possa encontrar uma vantagem de equilíbrio na legibilidade ou interoperabilidade humana, simplesmente não faz sentido usá-lo para armazenamento de dados.

XML É viável, dependendo do contexto. Se seus dados são bastante estáticos e não estão mudando muito (dados de exemplo, por exemplo), sim XML é um bom uso.

As definições de configuração, dados de amostra (mesmo que sejam milhões de linhas, mas raramente mudam), são todos bons usos do XML.

As leituras / gravações no disco rígido são caras, muito mais do que acessar dados de uma pilha Oracle / Sql.

Isso parece realmente enfatizar que o XML não deve ser usado para armazenamento de dados e deve ser usado apenas para interoperabilidade entre programas.

Sua premissa é falho.

O parágrafo que você cita está realmente dizendo que XML não é um substituto para um banco de dados , não que ele não deva ser usado para armazenamento de dados .

É claro que um arquivo de configurações não é a mesma coisa que um banco de dados e, portanto, diferentes tecnologias podem (e devem?) Ser usadas.

Corrija-me se estiver errado, mas você parece ter mais experiência com linguagens de marcação do que com bancos de dados. Se você tivesse um pouco de experiência com bancos de dados, perceberia em quais domínios as duas tecnologias diferentes são adequadas.

Isso é realmente subjetivo. Essa citação é, tipo, a opinião de alguém, cara.

Honestamente, acho que o XML é uma alternativa viável a um banco de dados, pois possui várias vantagens em relação a um RDMS, incluindo baixa sobrecarga, o que equivale a armazenamento mais barato (especialmente ao usar um serviço de hospedagem que cobra por bancos de dados separadamente).

Dê uma olhada em dasBlog e BlogEngine . Ambos os aplicativos usam xml para armazenamento como padrão.

Dito isto. Não é um RDMS e, se você tiver alta volatilidade (muitas atualizações, inserções ou exclusões) em seus dados ou exigir alta disponibilidade, use um banco de dados. XML é bom para armazenar pequenas coisas, como dados de configuração e dados de baixa volatilidade.

minha pergunta é: essa declaração ainda é válida e agora é aceitável armazenar dados usando XML?

Eu vejo o seu ponto no seu exemplo sobre os arquivos de configuração do .NET. No entanto, qualquer outro formato de arquivo poderia ter sido usado. De fato, antigamente, essas configurações eram armazenadas em arquivos de texto comuns chamados arquivos INI.

Vejo que a declaração que você apresentou em cinza é válida e correta se você definir um banco de dados como um sistema de software.

A definição de XML em XML-Definition afirma que "(XML) é uma linguagem de marcação que define um conjunto de regras para codificação de documentos em um formato legível por humanos e legível por máquina".

Essa definição se concentra na legibilidade e na linguagem, e não nos mecanismos para gerenciar os dados.

Comparado a um RDBMS, o XML não fornece meios para inserir e excluir aleatoriamente linhas em um arquivo XML. Por exemplo, se você tiver 1000000 linhas e desejar excluir linhas aleatoriamente, mesmo em um único arquivo baseado em XML do ambiente do usuário, não seria uma boa opção para um banco de dados. Além disso, o XML não fornece nenhum mecanismo nativo para bloquear dados. De fato, como XML não é um software, todas as propriedades ACID (atomicidade, consistência, isolamento, durabilidade) que garantem que as transações do banco de dados sejam processadas de maneira confiável em um ambiente compartilhado são deixadas para o desenvolvedor construir (com exceção da Durabilidade). O XML não possui uma especificação robusta para lidar com a integridade dos dados nos arquivos XML, muito menos em servidores diferentes (por exemplo, arquivo xml de cliente e arquivo xml de pedidos - sem FKs para reforçar a integridade).

O exposto acima não é uma enumeração do que falta ao XML; ele pode servir como uma justificação rápida da afirmação de que o XML não é um software de banco de dados .

O XML nunca quis ser um banco de dados ou substituí-lo.

XML é definido principalmente para documentos da Web que allows for the creation of customized tags for individual information fields., no entanto, você nunca obteria o gerenciamento centralizado de dados relacionais com ele.

Por que você realmente deseja usar XML para armazenar dados em primeiro lugar? Quero dizer, é uma língua depois de tudo ...

Embora se possa argumentar que é um formato flexível e fácil de entender, isso só se aplica quando é necessário editar manualmente os arquivos. Quando você realmente interage com o banco de dados com uma interface comum (busca dados X que atendem aos requisitos Y e Z, armazena / atualiza dados X, ...) essas vantagens se tornam nulas.

Resposta curta: Depende.

Resposta longa: Do meu ponto de vista, isso depende muito da quantidade de dados que você deseja armazenar. Por exemplo, se você possui alguns objetos em seu aplicativo durante o tempo de execução e deseja armazená-los após executar a ferramenta, um arquivo XML é perfeitamente adequado. No entanto, se sua loja virtual tiver 5000 clientes e ainda mais pedidos, um banco de dados seria um armazenamento de dados mais apropriado.

Além disso, acho que armazenar configurações em um banco de dados e não em um arquivo como app.config na maioria dos casos não é muito útil, mas acho que este exemplo não prova a citação.

XML é uma excelente opção para definições de configuração. Os arquivos XML não são fáceis de analisar / destacar em um IDE, mas são muito fáceis de editar por não programadores. Acho-os incrivelmente úteis em cenários de desenvolvimento da Web em que tarefas de manutenção estão sendo executadas por designers e gerenciadores de conteúdo.

O XML normalmente não deve ser usado como fonte de dados primária para aplicativos não triviais. Somente a sobrecarga de serialização / desserialização implora por uma solução diferente.

O termo banco de dados pode se referir apenas aos dados brutos ou também ao sistema de gerenciamento de banco de dados. Essa definição faz uma grande diferença em todo o argumento.

Se usarmos a definição RDBMS, o XML terá muito pouco nesse sentido. Você recebe muito pouco em termos de garantias ACID (você precisaria escrever seu próprio código para cumpri-las). Se você precisar desses (e a maioria dos sistemas transacionais precisa), você já está com problemas. Eu poderia dar uma lista de centenas de recursos que são tidos como garantidos com RDBMSes, que você teria que reinventar e reimplementar. Pense em modelos de segurança, replicação, backups, apenas para citar alguns modelos básicos.

No sentido acima, não, o XML não é um banco de dados e você não deve tentar usá-lo como um.

Se usarmos a definição de "dados brutos", o XML se sairá muito melhor, mas ainda assim não será ótimo. Como outros salientaram, porém, é extremamente detalhado em geral, geralmente sem codificação binária e com tags duplicadas, etc. Essas são trocas feitas para que o XML possa ser legível por humanos - basicamente, a eficiência é inimiga desse requisito. . O XML também não é particularmente adequado para as situações mais simples em que você insere registros continuamente. Supondo que você deseja que seu arquivo XML seja válido, você precisa de uma única tag de fechamento, o que significa que anexar um registro significa que você precisa alterar as tags no final. Isso é muito caro (como sabemos onde essa tag começa? E se houver várias "tabelas", apenas movemos o arquivo inteiro?) E, se você quiser contornar isso, você deve

Há situações em que o XML é apropriado - os arquivos de configuração são um ótimo exemplo, porque geralmente são pequenos e a legibilidade humana é um excelente recurso. Ter um banco de dados apenas para um arquivo de configuração pode ser um exagero.

Os bancos de dados, por outro lado, são excelentes quando você possui milhares (ou milhões / bilhões) de registros e muitos usuários os atualizam simultaneamente. Então, sim, o XML não é um banco de dados e você não deve usá-lo como um. Seu exemplo é uma daquelas situações em que você não precisava de um banco de dados e XML é o melhor ajuste.

O que eu vejo é o seguinte: se você usa XML como um banco de dados (por exemplo, como repositório de suporte para um sistema transacional), acabará reinventando e reescrevendo um RDBMS . Essa é uma maneira muito ruim de gastar seu tempo e energia. Eu acho que é isso que essa citação estava dizendo também.

Concordo que não é um banco de dados relacional. Eu acho que o autor está simplesmente dizendo na citação para não usá-lo como um.

Dito isto, embora você possa ou não precisar de um. Se você realmente não precisa fazer muita consulta sobre os dados, e apenas pretende armazená-los e buscá-los posteriormente com base em alguns critérios limitados de consulta, precisará de armazenamento e recuperação de DOCUMENT XML - não um banco de dados relacional.

Existem muitos aplicativos que simplesmente precisam armazenar um documento com dados para recuperação total posteriormente. Se esse for o caso, será inútil criar um esquema baseado em SQL, analisar o XML e serializá-lo no banco de dados apenas para fazer o inverso posteriormente. Há muita sobrecarga de código potencialmente envolvida nesse processo. Porém, há menos se você fizer certo.

Você pode usar ferramentas ORM como Hibernate e ferramentas como Apache Axis para gerar automaticamente praticamente todo o código necessário para criar um serviço que apenas lida com operações simples de CRU. É necessário agrupar isso na autenticação, é claro, e talvez você queira segregar os dados com base no usuário, nível de acesso, etc. Você pode até limitar as operações que um determinado usuário pode realizar via serviço SOAP para exemplo.

Nesse sentido, você está mais parecido com gerenciamento de conteúdo do que qualquer outra coisa.