Executando verificação de segurança...
2

O problema de quando uma chave estrangeira vira a chave primária

Então, esse foi o cenário que me deparei ao ser responsável por um sistema legado, mas que era responsável por gerar um faturamento expressivo para a empresa. Sendo assim, era uma aplicação crítica e que desempenhava bem para o contexto da qual ela foi construída.

Porém, não sei qual foi o motivo dos desenvolvedores terem implementado deste modo, mas umas das tabelas essenciais tinha sua chave primária contendo o valor de um dado recebido por outra aplicação terceira. Esse dado era justamente a chave privada de outra tabela. Nisso, quase chorei de lágrimas ao ver isso e não consegui descobrir motivos para essa implementação. Apenas aceitei tal como estava, já que não tinha escolha mesmo. Mas sabemos que a chave primária pode ter seu valor gerado serialmente pelo SGBD, no caso era o PostgreSQL.

De todo modo, esse pequeno detalhe foi o ponto que causou todo o pânico no time, pois agora o sistema teria que atender outra empresa. Esse projeto teria que forçar uma mudança no schema de dados para possibilitar uma arquitetura conhecida como Multi Tenant. O problema era a falta de tempo pelo prazo apertado e poucos devs atuando. Sendo assim, observei que existia um range nos valores da chave privada. Por exemplo:

O registro mais antigo persistia a chave primária com o valor 70001000.

Tendo isso em vista, pensamos numa gambiarra fantástica de preencher os valores abaixo desse range. Também, possibilitamos que a chave privada fosse gerada serialmente, caso a segunda empresa solicitasse uma requisição para nosso sistema. Contudo, essa implementação só funcionava bem até certo ponto e não era escalável se surgisse uma terceira empresa. O que foi o caso.

Chegando nesse ponto da situação, gostaria de alternativas para resolver esse cenário. Eu pensei em definir uma chave composta desta tabela. Sendo a chave primária - id - junto com outra coluna que poderia ser o id da empresa - reseller_id.

Por fim, temos que tal chave privada problemática é consultada por outros sistemas satélites. Então, qualquer mudança brusca na forma de consultar um registro pela primeira empresa, geraria problemas para gente. Enfim, achei legal compartilhar esse caso com a comunidade e ter ideia de visões diferentes da minha.

Carregando publicação patrocinada...
1

O melhor seria criar um ID para cada tenant, como você mencionou, um reseller_id ou mesmo tenant_id, criar o índice para otimizar as consultas e realizar o filtro do lado da aplicação.