Me deparei com uma pergunta sobre um tipo de dados para valores MD5 . A recomendação nessa pergunta afirma usar uuid
como tipo para esse campo.
A argumentação é sólida. Mas acho que isso pode ser confuso para alguém que não conhece os pontos revelados na pergunta acima. A decisão de usar uuid
como tipo MD5 é algo que eu gostaria de ver em alguma forma de documentação em qualquer projeto que faça isso.
Como um "ajudante" para quem olha para o DB Schema, pode-se argumentar para criar um md5
domínio herdado de uuid
. Dessa forma, os tipos de coluna ficariam muito mais explícitos e a intenção ficaria muito mais clara.
Mas usaria um domínio apenas para "renomear" um tipo existente.
Ainda é algo que faria sentido documentar adequadamente. Mas essa documentação poderia ser centralizada em uma seção explicando os domínios no banco de dados. Então você não ganharia nada em termos de documentação. A vantagem que vejo é, como mencionei, que a intenção fica clara ao olhar a tabela DDL.
Há alguma desvantagem nisso?
Embora não seja uma má ideia armazenar os metadados como o nome do tipo, eu não o faria. Essa é uma ladeira escorregadia que levará a um lugar bizarro onde
int
os s se tornam tipos mais específicos que não fornecem nada (no que diz respeito a restrições, para que servem os DOMAINs). Esses metadados sobre o que está na coluna pertencem ao nome da coluna , não ao tipo.Além disso, você pode explicá-lo com um PostgreSQL
COMMENT
Incapacidade de alterar os tipos subjacentes
De a_horse_with_no_name,
Outros problemas
Existem algumas esquisitices em relação a intervalos sobre domínios
Para quaisquer funções que usam o domínio, você deve garantir que os tipos de literais estejam no tipo de domínio.
Eu uso domínios liberalmente, mas apenas para adicionar restrições para que sejam gerenciados centralmente e não em uma mistura de instruções CHECK.