Esse documento busca apresentar boas práticas ou sugestões para deixar a implementação de um projeto mais agradável.
Colocar regras de negócio no banco é trêta. Pra corromper os dados por causa de uma procedure/trigger mais feita é daqui prali.
Nem toda implementação de ORM se dá muito bem com chave primária composta, então é bom evitar.
Uma coluna no banco que pode ser null, pode indicar a necessidade de criação de uma nova tabela de relação.
Chave estrangeira para um registros da mesma tabela. Quase sempre você vai querer associar mais informações (data de criação, quem associou, configurações diversas, etc). E isso vai sujar a tabela com uma ruma de coluna null, então criar uma tabela de relação é mais interessante.
Numa tabela de postagens de um blog, se for pedido para adicionar uma coluna de css ou javascript, pode ser melhor colocar uma coluna json.
Uma relação MxN pode ser usada para representar uma relação 1x1 sem precisar mexer na estrutura das tabelas relacionadas.
Dada uma tabela subscriptions e outra de bills, pode ser criada uma tabela
bill_subscription para representar uma relação 1x1 sem precisar mexer na
estrutura das relações. A restrição de 1x1 pode ser feita via código.
Seeds são usadas para inicializar o banco com dados de testes. Então usar uma seed em produção pode ser algo tretoso e sem sentido. Você quer dados de testes em produção? E se eu quiser desfazer, eu crio uma seed pra desfazer? A seed já foi rodada?
Esses problemas seriam resolvidos com migrations!
- Elas são executadas apenas uma vez
- Você sabe quando ela foi rodada
- Você pode desfazer as modificações que foram feita no banco
- Espera-se que as modificações da migrations seja algo final/produção
Segue alguns casos que é melhor criar uma migration ao invés de uma seed:
- Criar um usuário padrão (ex.: admin)
- Criar permissões para usuários
- Atualizar estrutura das tabelas e migrar os dados para outras colunas/tabelas