Quando devo usar XML em vez de SQL? [fechadas]

Há alguns anos trabalho com aplicativos da Web baseados em banco de dados e recentemente comecei um projeto envolvendo um CMS compatível com XML. Isso me levou a pensar sobre o uso de XML / XSLT em geral e em que situações seria mais útil do que a abordagem que sempre usei, que é armazenar todos os meus dados em um banco de dados (Meu) SQL e, em seguida, usar PHP / Python / etc. para trabalhar com ele na web conforme necessário.

Obviamente, há algo que não estou "entendendo" aqui ... alguém poderia me dar exemplos de aplicativos em que armazenar os dados em arquivos XML em vez de em um banco de dados seria preferível?

Para citar este livro (XML eficaz: 50 maneiras específicas de melhorar seu XML):

“XML não é um banco de dados. Nunca foi feito para ser um banco de dados. Nunca será um banco de dados. Os bancos de dados relacionais são 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 estão indo embora. XML é uma tecnologia muito útil para mover dados entre bancos de dados diferentes ou entre bancos de dados e outros programas. No entanto, ele não é um banco de dados. Não use como um. “

Acho que isso resume tudo, embora um pouco sem rodeios. XML é um formato de intercâmbio de dados. Pode-se ter bibliotecas de análise XML que podem consultar um DOM com expressões XPath, mas isso não é a mesma coisa que um DBMS. Você pode construir um DBMS com uma interface DOM / XPath, mas para obter propriedades ACID ou escalar para grandes conjuntos de dados, você precisa implementar um mecanismo de DBMS e um formato de dados com índices, registro e outros artefatos de um DBMS - o que (por definição) faz é algo diferente de XML.

Use XML para criar arquivos que precisam ser enviados a outros aplicativos. XML é mais adequado como formato de intercâmbio de dados do que como formato de armazenamento de dados.

O link a seguir não é ruim para descrever ao usar XML: Por que devo usar XML?

SQL são bons dados tabulares - dados que se encaixam facilmente em linhas e colunas. XML é bom para dados hierárquicos - dados que possuem vários níveis de tamanhos diferentes.

SQL é bom para armazenamento e pesquisa. XML é bom para transmissão e formatação.

1) Quando você tem que trocar seus dados com outras pessoas. XML é a " língua franca " da Web - quase todo mundo pode ler e interpretar, ao contrário de um arquivo de banco de dados.

2) Quando seu volume de dados é pequeno e você não tem que fazer consultas complexas contra ele. Os arquivos XML são bons para coisas como armazenar configurações ou modelos de documentos.

3) Quando você não tem muitos escritores tentando acessar os mesmos dados. Os bancos de dados SQL envolvem mecanismos de simultaneidade que funcionam nos bastidores para você. Os bancos de dados SQL podem suportar índices para a recuperação de informações em grandes conjuntos de dados rapidamente ...

Coisas para as quais uso XML:

• Persistindo uma hierarquia de objetos.
• Movendo dados de um processo ou máquina para outro.
• Dados que raramente mudam ou mudam; definições de configuração e similares.
• Como a entrada para as transformações de XSLT: de modo geral, se um dos meus programas emite HTML, está usando XSLT para fazer isso e, portanto, os dados de origem serão representados como XML em alguns
• Marcação de texto. (Não vamos esquecer isso!)

Não há muita sobreposição entre esses casos de uso e os casos de uso de um banco de dados. Um pouco, mas não muito.

Ironicamente, onde estou fazendo meu uso mais intenso de XML no momento é em um aplicativo de desktop que constrói um ADO DataSet na memória e usa os métodos WriteXml e ReadXml do DataSet para persistir e recuperá-lo. Estou usando ADO porque é muito mais fácil construir dinamicamente um modelo de dados definido por metainformação usando ADO do que seria implementar meu próprio modelo de objeto para a tarefa.

Portanto, aqui está um caso que parece que estou usando XML como banco de dados. Mas eu realmente não sou. Estou usando um modelo de objeto que implementa muitas funcionalidades semelhantes a banco de dados e estou usando XML como formato de persistência.

Acredito que existam alguns aplicativos comerciais que fazem uso intenso de XML como meio de armazenamento. Eu fiz isso para um aplicativo de planejamento de projeto, onde o usuário armazena cada projeto em seu próprio arquivo. O aplicativo fica em um stick USB e não requer instalação. Todos os dados são extraídos do XML e trabalhados na memória, então getRecord (id) é muito rápido.

Portanto, minha resposta seria ... quando os dados são pequenos o suficiente para serem mantidos na memória, um banco de dados está acabado.

Não.

Experimente SELECT autor FROM livro

Sempre que você não tiver o luxo de ter um banco de dados (pense em aplicativos de usuário único) ou precisar de um formato de armazenamento muito leve.

Também como o pôster anterior mencionado, um formato de intercâmbio.

XML e RDMSs podem ser usados ​​como datastores, mas cada implementação tem suas próprias vantagens e desvantagens.

Usar XML para armazenar dados para um aplicativo da web geralmente não é um grande problema até que você comece a lidar com grandes quantidades de dados ou decida que deseja descobrir outras informações de seus dados (exemplo: mineração de dados). Em outras palavras, armazenar grandes quantidades de arquivos XML para uma fonte de dados não é muito escalonável, mas torna mais fácil mover os dados. XML também pode ser usado para serializar objetos complexos em um formato não relacional, o que pode eliminar a necessidade de um ORM se você puder serializar / desserializar seus objetos diretamente do XML

Os RDMSs (bancos de dados) geralmente são mais escalonáveis, oferecem maior suporte à simultaneidade e são muito mais rápidos ao trabalhar com grandes quantidades de dados. O modelo relacional torna mais fácil a mineração de dados posteriormente. Os bancos de dados sofrem com a incompatibilidade de impedância relacional de objeto ( http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch ) que pode exigir que você escreva um código feio ou use ORMs complexos.

Eu iria, se limitasse os bancos de dados mysql em meu host, e veria a oportunidade de usar XML como um armazenamento de dados.

Aqui está um exemplo de uso de XML com SQL: Os usuários autenticados lêem e gravam dados em vários bancos de dados, nem todos são o mesmo DBMS. Os usuários da Empresa A usam dados de um banco de dados local do SQL Server. Os usuários da Empresa B usam dados de um banco de dados Oracle remoto. E assim por diante. Uma dúzia de bancos de dados diferentes, cada um com esquemas ligeiramente diferentes para os mesmos dados básicos.

O desenvolvedor do site não tem a capacidade de criar procedimentos armazenados nos bancos de dados remotos. O SQL deve ser enviado diretamente do aplicativo da web para o banco de dados. Como cada banco de dados tem uma sintaxe e um esquema SQL ligeiramente diferentes, é necessário usar SQL diferente para cada um dos 12 bancos de dados para a mesma operação (SELECT, INSERT, etc).

Uma das opções para incorporar as instruções SQL no aplicativo da web é colocá-las em arquivos XML. Cada arquivo XML contém o conjunto de instruções SQL para um dos doze bancos de dados. O código determina qual banco de dados é acessado para o usuário conectado e recupera o SQL apropriado do arquivo XML especificado.

Assim como acontece com os procedimentos armazenados, o SQL no arquivo XML pode ser atualizado sem interromper ou recompilar o aplicativo.

Alguns aplicativos usam arquivos XML para armazenar a configuração, prefiro usar o SQLite para fazer isso.

Eu nunca usaria nenhum tipo de XML para armazenar meus dados.

Usamos transformações XSLT como uma camada de abstração de dados em nosso aplicativo SOA. Todos os objetos enviam dados uns aos outros em XSLT, portanto, há apenas uma linguagem que eles precisam entender. Exceto pelo conector de banco de dados, que precisa ser capaz de transformar os dados em SQL, para enviá-los ao BD.

Dessa forma, você não tem geração de string SQL distribuída por um zilhão de objetos em seu aplicativo. Torna a manutenção muito mais fácil.