Diseñar un modelo de datos que dure años
Empezar por las entidades
Cuáles son las cosas del mundo — cliente, pedido, artículo, pago — y las relaciones entre ellas. Nombres que encajen con el lenguaje que habla el equipo de negocio ahorran incontables malentendidos.
No aplanes relaciones de muchos a muchos en campos de texto. “Etiquetas separadas por comas” es una deuda que se paga con dolor la primera vez que hay que filtrar por ellas.
Distinguir un hecho de un estado
Un estado actual cambia. Un hecho ocurrió. Un pedido tiene un estado; un pago es un evento que sucedió. Los sistemas que pierden la historia no pueden responder preguntas básicas como “cuál era el precio ese día”.
Así que: guarda registros de evento junto a los de estado, sobre todo en todo lo que toque dinero y permisos.
Campos que siempre valen la pena
Hora de creación y actualización, quién lo realizó, una versión o marca para detectar conflictos, y un borrado suave en vez de uno duro en sitios donde pueda hacer falta recuperar.
En profundidad
Cuando un modelo debe cambiar, prefiere añadir a borrar, y ejecuta el cambio como una migración por etapas. Y documenta las decisiones de modelo en breve — por qué hay dos tablas y no una — porque en un año nadie lo recordará, y la tentación de simplificar algo que fue deliberado es grande.