Como modelei compatibilidade de tipo sanguíneo no banco de dados

Parece simples: o doador tem um tipo sanguíneo, a campanha aceita certos tipos. Mas quando fui modelar isso no banco, percebi que tinha mais nuances do que esperava.

O problema

Compatibilidade de sangue não é só igualdade. Um doador O- pode doar para qualquer tipo. Um doador AB+ só pode doar para AB+. A lógica de compatibilidade existe e precisa estar em algum lugar do sistema.

A questão é onde: no banco, na aplicação ou nos dois?

O que eu fiz

Defini os tipos sanguíneos como enum no banco (A+, A-, B+, B-, AB+, AB-, O+, O-) e armazenei um array de tipos aceitos em cada campanha. A lógica de compatibilidade fica na aplicação, não no banco.

Isso significa que ao filtrar campanhas para um doador, a query traz campanhas onde o tipo do doador está no array de tipos aceitos. Simples e direto.

O que eu considerei e descartei

Criar uma tabela de compatibilidade com todas as combinações possíveis. Parece mais correto do ponto de vista relacional, mas adiciona complexidade sem benefício real para o caso de uso atual.

A lógica de compatibilidade completa (quem pode receber de quem) ficou como constante no código. Se as regras médicas mudarem, é um arquivo para atualizar.

O que aprendi

Nem todo problema de domínio precisa virar modelo de banco. Às vezes uma constante bem documentada resolve com mais clareza do que uma tabela a mais.