Vocês já lidaram com polimorfismo a nível de banco de dados?

Estou arquitetando um projeto grands no trabalho e optei por polimorfismo a nível de banco de dados.

Algo como:

tb_pessoa possui o id_pessoa, tb_funcionario tem o id_pessoa fazendo a relação com seus dados comuns a qualquer ser humano, assim "herdando" a tabela tb_pessoa.

Daí imagine outras coisas como tb_cargo que possui id_cargo, daí tb_funcionario possui id_cargo, assim herdando tb_pessoa e tb_cargo.

É muito massa porque dá pra fazer um mapa de herança do sistema. Também por se tratar de um ERP, cala cliente que é uma empresa no caso, possui seu próprio banco de dados, quando a pessoa contrata, o sistema réplica o banco de dados, assim dá pra atuar em vários países meio que de forma descentralizada e escalar infinitamente sem mudar o downtime nem degradar o sistema para outros contratantes.

É empolgante implementar coisas realmente boas.

Reply to this note

Please Login to reply.

Discussion

Dps que comecei a usar NoSQL anos atrás, cada ano que passa eu gosto menos de bancos relacionais, migrations, ORMs e etc.

Quando o sistema ta pequeno e com poucos registros, é tranquilo de desenvolver e dar manutenção, mas com o passar do tempo as coisas vão ficando mais complexas e as soluções já não servem pra implementar novas regras sem impactar o sistema.

No banco onde trabalho, temos mais de 700 microsservicos fora os legados, e é muito bom não ter que se preocupar varias coisas que uma API com varios Controllers e entidades que possuem regras entre si. Quando há necessidade de consultar em bancos relacionais, criamos procedures e pronto.

Pro meu caso específico banco relacional é melhor mesmo, o sistema já prevê banco de arquivamento. Vai manter apenas os últimos 5 anos de registro no banco de produção e mover automaticamente os registros mais antigos para um banco de arquivamento, então não tem problema de crescimento infinito inerente.

E a estrutura de banco de dados é modular, cada empresa terá seu próprio banco de dados, que pode inclusive ficar em instâncias diferentes etc, então é quase impossível entrar no problema de escala. Não é uma aplicação com um banco de dados central que vai escalar horizontalmente, é uma aplicação que escala horizontalmente com bancos de dados diferentes. Se fosse algo como um monolito que gostaríamos de escalar no futuro, talvez nosql faria mais sentido.

Sobre storage procedures a gente tem muito aqui no meu trabalho, mas eu considero uma solução para um problema de projeto mal definido, migrar regra de negócios pro banco de dados pra mim é sintomas de projeto feito por desenvolvedor Full Stack que não se aprofundou direito, entendendo o básico de arquitetura e o básico de banco de dados, aplicações server side e client side com pouco experiência. O correto na minha visão é você tratar o dado e sempre salvar o mais próximo possível do formato de consulta. Precisaria de um artigo pra demonstrações etc kkk

Mas também gosto de nosql, mas nunca usei em projetos grandes, até onde usei não acho que seja aplicável pra maioria dos projetos centralizados de pequena escala.

Isso aí foi extremamente inteligente. Eu já sei o que é polimorfismo e o que é banco de dados e etc, agora polimorfismo em banco de dados é a primeira vez que vejo

Muitos ORM, que utilizam linguaguens orientadas a objetos, trabalham assim.

Eu não sei o que é ORM...

A ideia do ORM é poder usar objetos da própria linguagem de programação para interagir com o banco. Isso evita ter que usar SQL diretamente.

Faz sempre o mínimo de tabela e vai colocando coluna, volte aqui depois de 5 anos.

Kkkk receita perfeita pra um sistema totalmente instável

Posso estar enganado, mas isso se trata de um banco relacional, polimorfismo não seria a melhor palavra.