¿Es mala práctica usar una sola tabla para almacenar datos de diferentes entidades?

Wine

Hola comunidad, estoy diseñando la base de datos para un sistema de gestión de inventarios y me surge una duda. Tengo tres tipos de elementos: productos físicos, servicios y consumibles digitales. Todos comparten atributos básicos (nombre, precio, fecha de creación) pero difieren en otros (peso, duración, enlace de descarga). Mi primera idea fue meter todo en una sola tabla con columnas nullable y un campo 'tipo' para diferenciarlos. Un compañero me dijo que eso es anti-patrón y que debo usar herencia de tablas. ¿Es realmente tan mala práctica? ¿Qué recomiendan?

Woodwork

Sin duda es un anti-patrón conocido como 'One True Lookup Table' o tabla única polimórfica. A corto plazo parece cómodo, pero a largo plazo tendrás problemas de integridad referencial, rendimiento (muchas columnas NULL) y mantenimiento. Te recomiendo usar herencia de tablas: una tabla base con los atributos comunes y tablas hijas con los específicos. Algo así:

CREATE TABLE items (
  id INT PRIMARY KEY,
  name TEXT,
  price DECIMAL,
  created_at TIMESTAMP,
  type TEXT CHECK (type IN ('product','service','digital'))
);

CREATE TABLE products (
  item_id INT PRIMARY KEY REFERENCES items(id),
  weight DECIMAL
);

CREATE TABLE services (
  item_id INT PRIMARY KEY REFERENCES items(id),
  duration INT
);

CREATE TABLE digitals (
  item_id INT PRIMARY KEY REFERENCES items(id),
  download_url TEXT
);

Así mantienes la normalización y evitas columnas nulas.

Wine

Gracias por la respuesta. Me parece lógico separar en tablas hijas, pero me preocupa un poco la complejidad de las consultas. Por ejemplo, si quiero listar todos los items con sus detalles específicos, tendría que hacer LEFT JOINs contra las tres tablas. ¿No afecta eso al rendimiento?

Drones

Buen punto, pero la solución no es meter todo en una tabla. Puedes usar vistas o, si tu motor lo soporta, tablas particionadas o JSON para los atributos variables. Otra opción: si los atributos específicos son pocos y poco consultados, podrías usar un campo JSONB en PostgreSQL. Eso te da flexibilidad sin romper la normalización del todo. Ejemplo:

CREATE TABLE items (
  id INT PRIMARY KEY,
  name TEXT,
  price DECIMAL,
  created_at TIMESTAMP,
  type TEXT,
  attributes JSONB
);

Así no tienes columnas NULL y las consultas simples son rápidas. Para búsquedas complejas sobre atributos, puedes indexar el JSONB.

Art

Ojo con JSONB: si necesitas integridad referencial o validaciones estrictas, no es ideal. Yo prefiero la herencia de tablas aunque las consultas tengan JOINs. Con índices adecuados no debería haber problema de rendimiento. Además, es más fácil de entender y mantener para otros desarrolladores.

Wine

Ambos enfoques tienen sentido. Creo que voy a ir por la herencia de tablas, porque la integridad es clave en mi proyecto. Gracias a todos por los consejos, me han aclarado las ideas.