Cita: Solución 1:
Tabla transaccion: Crear campos conforme los vaya necesitando.
Ni en tus peores pesadillas.
Tarde o temprano perderás el control de la estructura, de las relaciones y de la integridad de datos.
Cita: Solución 1:
Tablas transaccion: Crear solo los campos generales.
Tabla transaccion_detalle: Tenga 4 campos (id, transaccion_id, campo y valor) entonces cada campos que no sea general iría como un registro.
Un poco más cerca de la realidad. pero debes tener en cuenta que la realidad es mutable.
Esto quiere decir que si bien es una mejor solución, solamente el tiempo y la evolución el entorno del negocio definirán los cambios que se necesiten. en otras palabras, es una mejor base, pero no implica que a futuro no puedas necesitas sacar o poner cosas.
DE todos modos tres o cuatro campos pueden ser insuficientes para la definición formal de la transacción. Por las necesidades de consistencia de datos, usar tablas tan reducidas (basadas en taxonomías) implicará ingentes cantidades de validaciones programáticas.
Es más sencillo diseñar tablas de transacciones más normalizadas, e incluso agregar tablas para subconjuntos de datos, y no crear una tabla multiuso.
Conozco una base de datos empresaria donde las transacciones como las que describes usan un esquema de más de veinte tablas, según las necesidades de la operación, y no por eso es poco eficiente ni complejo. Es sumamente poderosa y muy eficiente.
Obviamente por detrás hay varios equipos de desarrollo para la BBDD y para las aplicaciones...
Cita: ¿Alguien ha implementado algo así?
SI: Todas las empresas que operan comercialmente lo han hecho. Pero es muy habitual que la solución sea muy distinta de una a otra.
La regla central del asunto es que no hay un método unificado para solucionarlo, sino que dependen del negocio, y de los requisitos de cada empresa. Y en ese sentido lo que debes analizar es qué requerimientos tiene TU emprendimiento, y ver qué es lo que necesita.
Recuerda: no hay reglas absolutas.
