Por toda a sua popularidade e sucesso, o SQL é um estudo em paradoxo. Pode ser desajeitado e detalhado, mas para os desenvolvedores, geralmente é a maneira mais simples e direta de extrair os dados que queremos. Pode ser um raio rápido quando uma consulta é escrita corretamente e lenta como melaço quando a consulta perde a marca. Tem décadas, mas corado com novos recursos.
Esses paradoxos não importam porque o mercado falou: o SQL é a primeira escolha para muitos, mesmo com opções mais recentes e sem dúvida mais poderosas. Desenvolvedores em todos os lugares – desde os menores sites até as maiores mega corporações – Know SQL. Eles confiam nele para manter todos os seus dados organizados.
O modelo tabular do SQL é tão dominante que muitos projetos não-SQL acabam adicionando um Sql-ish interface porque os usuários exigem. Isso é verdade até o movimento NOSQL, que foi inventado para se libertar do antigo paradigma. No final, ao que parece, o SQL venceu.
As limitações do SQL podem não ser suficientes para levá -lo ao lixo da história. Os desenvolvedores nunca podem se levantar e migrar todos os seus dados do SQL. Mas seus problemas são reais o suficiente para gerar estresse, adicionar atrasos e até exigir reengenharia para alguns projetos.
Aqui estão treze razões pelas quais desejamos poder deixar o SQL, mesmo que provavelmente não o faremos.
13 maneiras pelas quais o SQL piora as coisas
- As mesas não escalam
- SQL não é JSON- ou XML-nativo
- Marshalling é um grande tempo de picante
- SQL não faz em tempo real
- Juns são uma dor de cabeça
- Colunas são um desperdício de espaço
- A otimização só ajuda às vezes
- A desnormalização trata tabelas como lixo
- Idéias aparafusadas podem destruir seu banco de dados
- A sintaxe SQL é muito frágil, mas não frágil o suficiente
- Nem tudo é uma mesa
- SQL não é tão padrão
- Existem opções melhores
As mesas não escalam
O modelo relacional adora tabelas, então continuamos construindo -as. Isso é bom para bancos de dados de tamanho pequeno ou mesmo normal. Mas o modelo começa a quebrar em escalas verdadeiramente grandes.
Alguns tentam resolver o problema, reunindo antigos e novos, como integrar o sharding em um banco de dados de código aberto mais antigo. Adicionar camadas pode parecer tornar os dados mais simples de gerenciar e oferecer escala infinita. Mas essas camadas adicionadas podem ocultar minas terrestres. UM SELECT ou a JOIN pode levar muito tempo para processar, dependendo da quantidade de dados armazenados nos fragmentos.
Sharding também força o DBA a considerar a possibilidade de que os dados possam ser armazenados em uma máquina diferente, ou possivelmente até em uma localização geográfica diferente. Um administrador inexperiente que começa a pesquisar em uma tabela pode ficar confuso se não perceber que os dados são armazenados em diferentes locais. O modelo às vezes abstrava o local longe da vista.
Algumas máquinas da AWS vêm com 24 terabytes de RAM. Por que? Porque alguns usuários de banco de dados precisam tanto. Eles têm tantos dados em um banco de dados SQL e funcionam muito melhor em uma única máquina e em um único bloco de RAM.
SQL não é JSON- ou XML-nativo
O SQL pode ser sempre verde como um idioma, mas não joga particularmente bem com formatos mais recentes de troca de dados como JSON, YAML e XML. Todos os três suportam um formato mais hierárquico e flexível do que o SQL. As tripas dos bancos de dados SQL ainda estão presos no modelo relacional com tabelas em todos os lugares.
O mercado encontra maneiras de atender a essa reclamação comum. É relativamente fácil adicionar um formato de dados diferente, como o JSON com o código de cola certo, mas você pagará com o tempo perdido.
Alguns bancos de dados SQL podem codificar e decodificar formatos de dados mais modernos como JSON, XML, GraphQL ou YAML como recursos nativos. Mas por dentro, os dados geralmente são armazenados e indexados usando o mesmo modelo tabular antigo. A formatação JSON é apenas uma fachada que pode facilitar a vida do desenvolvedor, mas também pode ocultar os custos de conversão.
Quanto tempo é gasto convertendo dados dentro e fora desses formatos? Não seria mais fácil armazenar nossos dados de uma maneira mais moderna? Alguns desenvolvedores de banco de dados inteligentes continuam a experimentar, mas o estranho é que eles geralmente acabam aparecendo em algum tipo de analisador SQL. É isso que os desenvolvedores dizem que querem.
Marshalling é um grande tempo de picante
Os bancos de dados podem armazenar dados em tabelas, mas os programadores escrevem código que lida com objetos. Parece que grande parte do trabalho de projetar aplicativos orientados a dados está descobrindo a melhor maneira de extrair dados de um banco de dados e transformá-los em objetos que a lógica de negócios pode utilizar. Em seguida, os campos de dados do objeto devem ser soltos, transformando -os em um SQL UpSert. Não existe uma maneira de deixar os dados em um formato que está pronto para ir?
SQL não faz em tempo real
O banco de dados SQL original foi projetado para análise de lote e modo interativo. O modelo de streaming de dados com tubulações de processamento longo é uma ideia relativamente nova e não corresponde exatamente.
Os principais bancos de dados SQL foram projetados décadas atrás, quando o modelo imaginou o banco de dados se sentando por conta própria e respondendo a perguntas como algum tipo de Oracle. Às vezes eles respondem rapidamente, às vezes não. É assim que o processamento em lote funciona.
Alguns dos aplicativos mais recentes exigem melhor desempenho em tempo real-não apenas por conveniência, mas porque o aplicativo exige. Sentado como um guru em uma montanha não funciona tão bem no mundo dos streaming.
Os bancos de dados mais recentes projetados para esses mercados colocam um prêmio em velocidade e capacidade de resposta. Eles não oferecem o tipo de consultas SQL elaboradas que podem diminuir tudo.
Juns são uma dor de cabeça
O poder dos bancos de dados relacionais vem da divisão de dados em tabelas menores e mais concisas. A dor de cabeça vem depois.
Os dados remontando em tempo real com junções geralmente são a parte mais computacionalmente cara de um trabalho, porque o banco de dados precisa fazer malabarismos com todos os dados. As dores de cabeça começam quando os dados começam a superar a RAM.
As junções podem ser incrivelmente confusas para quem aprende SQL. Descobrir a diferença entre as junções interno e externo é apenas o começo. Encontrar a melhor maneira de conectar várias junções é ainda pior.
Colunas são um desperdício de espaço
Uma das grandes idéias do NOSQL estava dando aos usuários liberdade das colunas. Se alguém quisesse acrescentar um novo valor a uma entrada, poderia escolher qualquer tag ou nome que quisesse. Não havia necessidade de atualizar o esquema para adicionar uma nova coluna.
Os defensores do SQL veem apenas o caos nesse modelo. Eles gostam do pedido que vem com mesas e não querem que os desenvolvedores adicionam novos campos em tempo real. Eles têm razão, mas adicionar novas colunas pode ser caro e demorado, especialmente em grandes mesas. Colocar os novos dados em colunas separadas e combiná -los com junções adiciona ainda mais tempo e complexidade.
A otimização só ajuda às vezes
Empresas e pesquisadores de banco de dados passaram muito tempo desenvolvendo bons otimizadores que desmontam uma consulta e encontram a melhor maneira de encomendar suas operações.
Os ganhos podem ser significativos, mas há limites para o que um otimizador pode fazer. Se o administrador do banco de dados enviar uma consulta complicada, haverá muito o otimizador.
Alguns DBAs apenas aprendem isso quando o aplicativo começa a escalar. As primeiras otimizações são suficientes para lidar com os conjuntos de dados de teste durante o desenvolvimento. Mas na hora da crise, o otimizador atinge uma parede. Há muito suco que o otimizador pode espremer de uma consulta. De uma consulta.
A desnormalização trata tabelas como lixo
Os desenvolvedores geralmente se vêem presos entre usuários que desejam desempenho mais rápido e balcões de feijão que não querem pagar pelo hardware. Uma solução comum é desnormalizar as tabelas para que não haja necessidade de junções complexas ou nada de tabular. Todos os dados já estão lá em um retângulo longo.
Esta não é uma solução técnica ruim, e muitas vezes vence porque o espaço do disco se tornou mais barato que o poder de processamento. Mas a desnormalização também joga de lado as partes mais inteligentes do SQL e da teoria do banco de dados relacional. Toda essa energia sofisticada do banco de dados é praticamente obliterada quando seu banco de dados se torna um arquivo CSV longo.
Idéias aparafusadas podem destruir seu banco de dados
Os desenvolvedores adicionam novos recursos ao SQL há anos, e alguns são bastante inteligentes. É difícil ficar chateado com os recursos legais que você não precisa usar. Por outro lado, esses sinos e assobios são frequentemente aparafusados, o que pode levar a problemas de desempenho. Alguns desenvolvedores alertam que você deve ter um cuidado extra com as subconhas, porque eles diminuem tudo. Outros dizem que a seleção de subconjuntos como expressões de tabela comuns, visualizações ou Windows complica demais seu código. O criador do código pode lê -lo, mas todo mundo fica com dor de cabeça tentando manter todas as camadas e gerações de SQL reto. É como assistir a um filme de Christopher Nolan, mas em código.
Algumas dessas grandes idéias atrapalham o que já funciona. As funções da janela foram projetadas para tornar mais rapidamente a análise básica de dados, acelerando o cálculo de resultados como médias. Mas muitos usuários do SQL usarão algum recurso para aparafusar. Na maioria dos casos, eles tentarão o novo recurso e apenas perceberão que algo está errado quando a máquina diminui para um rastreamento. Então eles precisarão de um DBA idosos para explicar o que aconteceu e como consertá -lo.
A sintaxe SQL é muito frágil, mas não frágil o suficiente
No passado distante, quando o SQL nasceu, apenas os humanos escreveriam SQL. Agora, tantos sistemas costuram consultas automaticamente. Isso oferece aos usuários ingênuos ou maliciosos muito poder para fazer coisas ruins.
Os DBAs aprendem rapidamente a evitar palavras reservadas, mas isso não ajuda o usuário casual que pode querer usar o “Select Group” como uma coluna. E depois há as maravilhosas soluções padrão para escapar de palavras reservadas como “Selecionar”. O MySQL usa ticks de volta. O PostgreSQL usa cotações duplas. Apenas certifique -se de usar o certo para a sua versão do SQL.
Para piorar a situação, os atacantes inteligentes podem atingir esse ponto fraco injetando comandos SQL em consultas. Em vez de apenas digitar seu nome em um campo, as entradas do atacante ; DROP TABLE users; DROP TABLE products; DROP TABLE orders;--. O analisador SQL está feliz em fazer o que é dito. Afinal, foi escrito em uma época em que apenas os humanos emitiram as consultas.
Nem tudo é uma mesa
Uma quantidade surpreendentemente grande de dados se encaixa perfeitamente nas tabelas, mas uma quantidade crescente de dados não se encaixa perfeitamente. Por exemplo, redes sociais, dados hierárquicos e muitos fenômenos científicos são modelados com gráficos. Estes podem ser armazenados em tabelas, mas fazer algo além da consulta mais simples se torna complexa. E há dados espaciais em duas ou três dimensões. Pelo menos os dados da série temporal têm apenas um eixo principal.
Outros dados existem em duas, três ou talvez até várias dimensões. As tabelas, no entanto, têm apenas um eixo para as linhas e um eixo subordinado para as várias colunas. Isso significa que o armazenamento de dados bidimensionais como latitude e longitude é possível, mas cálculos multidimensionais como a distância não são fáceis. Novas extensões geográficas podem consertar sobre ela, mas o paradigma ainda limita.
SQL não é tão padrão
O SQL pode ser um padrão ANSI/ISO, mas isso não significa que você pode simplesmente movê-lo de uma implementação de suporte padrão para outra. Você deve estar pensando em outro significado da palavra padrão.
Os DBAs estão muito familiarizados com a grande variedade de diferenças sintáticas. MySQL usa “CURDATE()“, Oracle usa”SYSDATE”, E PostgreSQL usa“CURRENT_DATE”. SQL Server permite concatenar strings com um“+Operador. Outros querem duas linhas verticais (“||”).
As dezenas de incompatibilidades sintáticas são apenas o começo. Existem grandes diferenças filosóficas entre as implementações de procedimentos armazenados, gatilhos e funções apoiadas. Até os tipos de dados fundamentais têm nuances em sua precisão e alcance.
Existem opções melhores
As equipes de TI devem frequentemente se contentar com o que já existe. A melhor razão pela qual o SQL precisa ir é que temos melhores alternativas mais concisas, flexíveis e legíveis. O GraphQL, por exemplo, é frequentemente encontrado em aplicativos da Web, onde é usado para solicitar as combinações corretas de dados com um padrão simples. Os dados hierárquicos são naturalmente suportados.
Já existem várias boas opções para pesquisar nos bancos de dados NoSQL. Muitas das lojas de valor-chave procuram nós correspondentes. Alguns, como a linguagem de consulta MongoDB (MQL), imitam o popular padrão JSON. Os desenvolvedores que usam algumas das soluções centradas em documentos, como Solr ou pesquisa elástica, podem usar funções complexas de similaridade.
Tudo isso pode suportar consultas mais poderosas e mais fáceis para os seres humanos de ler e criar. Eles criam possibilidades para armazenar dados que não se limitam às tabelas cheias de linhas e colunas. Que visão estreita do mundo é isso.
