What Goes Around Comes Around

o problema

Antes do modelo relacional, guardar dados exigia decidir a estrutura física junto com a lógica. O IMS, de 1968, obrigava os tipos de registro a formar uma árvore. Para o exemplo canônico de fornecedores e peças, isso força uma de duas escolhas ruins: repetir a informação da peça sob cada fornecedor, ou repetir o fornecedor sob cada peça. Nos dois casos o dado repetido pode ser alterado num lugar e não no outro. Pior: a existência passa a depender do pai, e não há como registrar uma peça que ninguém fornece. O CODASYL trocou a árvore por uma rede e resolveu isso, ao custo de o programador navegar num hiperespaço mantendo na cabeça indicadores de currency — o último registro tocado, o último de cada tipo, o último de cada set. Bachman chamou isso de navegar; era programar olhando um mapa de parede cheio de alfinetes coloridos.

Em 2005 o autor viu a mesma coisa voltando com outro nome. XMLSchema tinha hierarquia como no IMS, referências entre registros como no CODASYL, atributos com valores de conjunto e herança múltipla como nos modelos semânticos, e ainda union types, que ninguém em banco de dados jamais propôs porque um índice sobre union type precisa de um índice por tipo base e um plano por combinação. O paper existe para dizer que essa proposta já foi testada e já fracassou, e que os proponentes eram jovens demais para ter assistido.

a ideia

Reescrever 35 anos de propostas na mesma notação e no mesmo exemplo — fornecedor, peça, fornecimento — e ver o que sobra quando a sintaxe idiossincrática sai. Sobram poucas ideias, repetidas em ciclos de uma década. O paper agrupa tudo em nove eras e fecha cada uma com uma lição numerada.

Duas perguntas explicam quase todos os desfechos. Quanta independência de dados o modelo entrega? E quanta complexidade ele cobra por isso? Em vinte anos, os autores só encontram duas ideias genuinamente novas: código dentro do banco e schema-last.

como funciona

O método é eliminatório. O IMS cai porque a DL/1 é record-at-a-time: o programador escreve o algoritmo e o banco executa.

Get unique Supplier (sno = 16)
Until failure do
  Get next within parent (color = red)
Enddo

Existe uma segunda solução, varrendo todas as peças vermelhas, e ela é mais rápida se o banco tiver um fornecedor só. Quem decide é o programador, a cada consulta, para sempre.

A era R++ cai por outro motivo. O Gem propôs atributo com valor de conjunto, tupla como tipo de dado (com notação de ponto encadeado, para atravessar tabelas sem escrever join) e generalização. Tudo elegante, tudo simulável com chave estrangeira, nenhum ganho de performance — e os fornecedores relacionais estavam ocupados com throughput de transação, que valia dinheiro. Os modelos semânticos morrem pela mesma conta. Os OODBs entregam C++ persistente rodando no mesmo espaço de endereçamento da aplicação, o que os deixa rápidos para abrir um objeto de CAD e sem transação, sem consulta declarativa e sem proteção — e sem mercado, porque evitar escrever um load e um unload não é dor suficiente para o cliente pagar.

Sobra o object-relational. O Postgres arrancou os tipos, operadores e access methods embutidos e os tornou definíveis pelo usuário, o que resolve consulta geográfica que B-tree não atende. O benchmark Bucky depois mostrou onde estava o ganho: nos UDTs e UDFs, não nos construtos objeto. Uma UDF é o stored procedure do Sybase — inventado para cortar seis round trips do TPC-B para um — generalizado para linguagem de verdade e chamável no meio de uma consulta.

o que isso custou

É um paper de opinião escrito por participantes. O primeiro autor assina INGRES e Postgres, e os vencedores da história narrada são exatamente o relacional e o object-relational. A única evidência quantitativa citada é um benchmark de terceiros. A taxonomia de quatro classes de aplicação, que sustenta a conclusão de que schema-last é nicho, é defendida por exemplos escolhidos — currículos, anúncios, descrições de curso, o Monster.com adotando formulário — e não por levantamento.

A lição de que o mercado decide explica tudo depois do fato e não prevê nada antes dele. O escopo também é estreito: o texto trata de modelo de dados e linguagem de consulta, e deixa de fora distribuição, tolerância a falhas e armazenamento. Os próprios autores admitem que avanço tecnológico muda as regras e que por isso esperam uma sucessão de novos padrões; sobre XML eles não preveem, apenas listam três cenários possíveis, um deles a piada de que alguém reinventaria Codd e ganharia o Turing por volta de 2015.

onde isso aparece hoje

O paper virou leitura obrigatória de disciplina de banco de dados, e a razão é o critério que ele fixa: julgue proposta nova pela independência de dados que entrega e pela complexidade que cobra. Ler A Relational Model of Data for Large Shared Data Banks depois deste texto muda o que se enxerga lá.

A previsão sobre XML se cumpriu na parte que importava: virou formato de transporte universal e não virou motor de banco — bancos XML nativos ficaram no nicho. O schema-last voltou mesmo assim, agora como documento JSON e schema-on-read, e junto voltou a conta da heterogeneidade semântica que o paper descreve, a de reconciliar registro por registro em vez de esquema por esquema. Dezenove anos depois o argumento ganhou uma sequência, What Goes Around Comes Around… And Around…, que refaz o exercício com as eras que vieram depois.