Si estuviera usando un RDBMS (por ejemplo, SQL Server) para almacenar datos de origen de eventos, ¿cómo sería el esquema?
He visto algunas variaciones de las que se habla en un sentido abstracto, pero nada concreto.
Por ejemplo, digamos que uno tiene una entidad "Producto", y los cambios en ese producto podrían venir en forma de: Precio, Costo y Descripción. Estoy confundido acerca de si:
- Tener una tabla "ProductEvent", que tenga todos los campos de un producto, donde cada cambio significa un nuevo registro en esa tabla, más "quién, qué, dónde, por qué, cuándo y cómo" (WWWWWH) según corresponda. Cuando se cambia el costo, el precio o la descripción, se agrega una fila completamente nueva para representar el Producto.
- Almacene el costo, el precio y la descripción del producto en tablas separadas unidas a la tabla Producto con una relación de clave externa. Cuando se produzcan cambios en esas propiedades, escriba nuevas filas con WWWWWH según corresponda.
- Almacenar WWWWWH, más un objeto serializado que representa el evento, en una tabla "ProductEvent", lo que significa que el evento en sí debe cargarse, eliminarse de la serialización y reproducirse en el código de mi aplicación para reconstruir el estado de la aplicación para un Producto dado. .
Particularmente me preocupa la opción 2 anterior. Llevada al extremo, la tabla de productos sería casi una tabla por propiedad, donde cargar el Estado de la aplicación para un producto dado requeriría cargar todos los eventos para ese producto desde cada tabla de eventos de producto. Esta explosión de mesa me huele mal.
Estoy seguro de que "depende", y aunque no hay una única "respuesta correcta", estoy tratando de tener una idea de lo que es aceptable y lo que es totalmente inaceptable. También soy consciente de que NoSQL puede ayudar aquí, donde los eventos podrían almacenarse en una raíz agregada, lo que significa que solo una solicitud a la base de datos para obtener los eventos para reconstruir el objeto, pero no estamos usando una base de datos NoSQL en el momento, así que estoy buscando alternativas.