Con tantos hilos por aquí de esquemas que hay que retocar a medio proyecto porque un requisito cambió, van algunos trucos que uso para que un diseño de base de datos aguante mejor los cambios que inevitablemente llegan:

1. Claves primarias artificiales (surrogate keys), casi siempre. Usar un id autoincremental en vez de una clave natural (DNI, email, código de producto) como clave primaria. Las claves naturales cambian con más frecuencia de la que parece al diseñar (un email se actualiza, un código se reasigna), y si es tu clave primaria, ese cambio se propaga a todas las tablas que la referencian.

2. Evitar columnas tipo «estado» con valores fijos en texto libre. Si un pedido puede estar «pendiente», «enviado» o «entregado», mejor una tabla de estados con su propio id que una columna VARCHAR con esos textos repetidos. Añadir un estado nuevo después es una fila nueva, no una migración que reescribe datos existentes.

3. Fechas de auditoría desde el primer día. created_at, updated_at en prácticamente cada tabla, aunque no los necesites hoy. Añadirlos después en una tabla con datos ya en producción significa que todo lo histórico se queda sin esa información, mientras que tenerlos desde el principio no cuesta prácticamente nada.

4. Relaciones muchos-a-muchos con tabla intermedia desde el principio, aunque hoy solo parezca uno-a-muchos. Es mucho más barato tener una tabla intermedia sin usar de más que descubrir a mitad de proyecto que un producto necesita pertenecer a varias categorías y toca migrar toda la relación.

Ninguno de estos trucos evita del todo tener que migrar algún día, pero reducen bastante la frecuencia de los cambios realmente dolorosos (los que tocan la clave primaria o rompen relaciones existentes).

Nuria

Un par de trucos que a mí me han ahorrado bastantes dolores de cabeza con el tiempo:

1. Claves subrogadas (autoincrementales o UUID) en todas las tablas, incluso cuando parece que ya tienes una clave natural obvia. Las claves naturales tienden a dejar de ser tan "naturales" cuando cambian los requisitos (un DNI que resulta que no es único entre países, un código de producto que la empresa decide renombrar), y si esa clave natural está sembrada como FK por todo el esquema, cambiarla después es un infierno.

2. Evitar columnas "multiuso" que cambian de significado según el contexto (un campo tipo genérico que determina qué significan otras tres columnas de la misma fila). Parece flexible al principio, pero en cuanto los requisitos cambian, acabas con lógica de aplicación llena de condicionales para saber qué campo mirar según el tipo, en vez de que el propio esquema te lo garantice.

3. Meter herramientas de migraciones (Flyway, Liquibase, o lo que use tu stack) desde el primer día, no cuando ya duele. Cuando el esquema cambia con el proyecto en producción, tener versionados y reproducibles todos los cambios es lo que de verdad te permite adaptarte sin miedo, más que cualquier decisión concreta de diseño inicial.

Ivan