Projetar um modelo de dados que dure anos
Começar pelas entidades
Quais são as coisas no mundo — cliente, pedido, item, pagamento — e as relações entre elas. Nomes que combinam com a linguagem que o time de negócio fala evitam incontáveis mal-entendidos.
Não aplane relações muitos-para-muitos em campos de texto. 'Tags separadas por vírgula' é uma dívida paga com dor na primeira vez que você precisar filtrar por elas.
Distinguir um fato de um estado
Um estado atual muda. Um fato — aconteceu. Um pedido tem um estado; um pagamento é um evento que ocorreu. Sistemas que perdem o histórico não conseguem responder perguntas básicas como 'qual era o preço naquele dia'.
Então: guarde registros de evento ao lado dos de estado, especialmente em tudo que toca dinheiro e permissões.
Campos que sempre valem a pena
Horário de criação e atualização, quem executou, uma versão ou carimbo para detectar conflitos, e exclusão suave em vez de dura em lugares onde pode ser preciso recuperar.
Indo mais fundo
Quando um modelo precisar mudar, prefira adição à remoção, e execute a mudança como uma migração em etapas. E documente decisões de modelo brevemente — por que há duas tabelas e não uma — porque em um ano ninguém vai lembrar, e a tentação de simplificar algo deliberado é grande.