Entidade e Relacionamento

Introdução

Numa era anterior à internet de fibra óptica, a bancos relacionais modernos e ao hype dos frameworks, existia um mundo mais cru – mas também mais realista. Um mundo em que desenvolvedores precisavam lidar com problemas como corrompimento de índices, limitações de arquivos DB, redes com cabos coaxiais e disquetes de instalação. E foi nesse mundo que eu descobri, talvez por necessidade mais do que por filosofia, que às vezes relacionamentos físicos entre tabelas mais atrapalham do que ajudam.

Estou falando do Paradox, um dos bancos de dados mais usados nos anos 90. E estou falando de milhões de registros, rodando em rede, até hoje, com performance aceitável e sem nenhum relacionamento entre tabelas.

A era Paradox: onde tudo começou

Quando comecei a construir sistemas com Paradox, a documentação incentivava a criação de relacionamentos entre tabelas. Era quase dogma. Usava-se o Database Desktop, criavam-se as estruturas, definiam-se chaves estrangeiras e pronto: parecia tudo resolvido.

Até que não estava.

Os problemas

• Travamentos constantes ao abrir registros relacionados em máquinas simultâneas.
• Corrompimento de índices em operações comuns.
• Dificuldade de backup: o sistema exigia sequências exatas para não corromper os relacionamentos.
• Migrações traumáticas: trocar uma chave primária em uma tabela implicava quebrar referências em cascata.

E então, cansado de lidar com essas limitações, tomei uma decisão radical: abandonei todos os relacionamentos físicos. As tabelas tornaram-se autônomas, mas os dados continuaram se relacionando por meio da lógica no código.

A descoberta: dados precisam de significado, não de amarras

Ao eliminar os relacionamentos físicos, eu passei a:

• Controlar a integridade na aplicação, validando manualmente as operações.
• Assumir total responsabilidade pela consistência dos dados, inclusive em exclusões, edições e inserções.
• Agir como um orquestrador consciente, e não como um delegador automático.

O resultado foi surpreendente:

• A performance melhorou consideravelmente.
• Os problemas de corrupção de dados praticamente desapareceram.
• A manutenção do sistema ficou mais previsível e controlada.

Na prática, eu troquei garantias "cômodas" do banco por um modelo muito mais robusto na lógica da aplicação.

Mas não fui o único...

Hoje vejo que, ao fazer isso, eu não estava errado – estava à frente do meu tempo. Arquiteturas modernas como Event Sourcing, CQRS e sistemas de microserviços desacoplados evitam relacionamentos físicos exatamente pelo mesmo motivo: manter a autonomia, controle e flexibilidade dos dados.

Além disso, em bancos como MongoDB, DynamoDB ou até mesmo SQLite em sistemas mobile, é comum delegar a integridade para o código da aplicação, especialmente quando o acesso ao banco é sempre mediado por uma API ou middleware.

Muitos desenvolvedores experientes hoje compartilham dessa filosofia:

“Se posso garantir a integridade no código, não deixo o banco tomar essa responsabilidade por mim.”

O tempo passou... mas a ideia ficou

30 anos depois, ainda tenho sistemas rodando com essa mesma filosofia. Hoje não uso mais Paradox para novos sistemas, claro. Mas mesmo em bancos modernos como SQLite, SQL Server e PostgreSQL, continuo seguindo o mesmo princípio.

Porque entendo que:

• Relacionamentos físicos não garantem qualidade – só garantem rigidez.
• A lógica é mais importante do que a estrutura – a estrutura deve servir à lógica, e não o contrário.
• Frameworks mudam, ferramentas mudam, bancos mudam – mas o controle consciente permanece.

Mas relacionamentos físicos têm seu lugar

Nem todo sistema exige performance máxima ou controle refinado da lógica. Em muitos contextos, especialmente em aplicações menores, CRUDs simples, protótipos, ou sistemas com poucos usuários e regras de negócio estáveis, usar os relacionamentos físicos oferecidos pelo banco é uma escolha válida e até recomendável.

Eles ajudam a:

• Evitar erros triviais, como registros órfãos.
• Reduzir a complexidade inicial do desenvolvimento.
• Aproveitar a infraestrutura do banco para garantir integridade básica.

O importante é que a decisão seja consciente.

Usar relacionamentos físicos por padrão cego pode limitar seu sistema.
Recusá-los por rebeldia ideológica também.
O ponto de equilíbrio está na necessidade real do projeto.

Lições aprendidas

• A simplicidade controlada é mais poderosa do que a automação cega.
• Quem entende o domínio, deve controlar as regras.
• Modelos rígidos dificultam a evolução – e evolução é o que mantém um sistema vivo.
• Ao abrir mão de relacionamentos físicos, você não perde controle. Você o conquista.

Conclusão

O que parecia uma "loucura" 30 anos atrás, hoje é uma das minhas maiores convicções: os dados podem ser controlados por quem entende deles.

O uso consciente de relacionamentos físicos é válido, claro. Mas quando você decide abandoná-los, não está cometendo um erro. Está, na verdade, assumindo a responsabilidade completa pela inteligência do seu sistema.

“Não é a tecnologia que garante a durabilidade do software. É o pensamento por trás dela.”