En una de nuestras bases de datos, distinguimos entre transactional y dictionary registros.
En pocas palabras, transactional los registros son cosas que no se pueden revertir en la vida real, como una llamada de un cliente. Puede cambiar el nombre de la persona que llama, el estado, etc., pero no puede descartar la llamada en sí.
Dictionary los registros son cosas que puedes cambiar, como asignar una city a un cliente.
Transactional registros y cosas que conducen a ellos nunca se eliminaron, mientras que dictionary los que podrían borrarse bien.
Por "cosas que conducen a ellas" me refiero a que tan pronto como aparezca el registro en las reglas de negocio que pueden conducir a una transactional registro, este registro también se vuelve transactional .
Como, una city se puede eliminar de la base de datos. Pero cuando apareció una regla que decía "enviar un SMS a todos los clientes en Moscú ", las ciudades se volvieron transactional registros también, o no podríamos responder a la pregunta "¿por qué este SMS ser enviado".
Una regla general para distinguir era esta:¿es solo el negocio de mi empresa?
Si uno de mis empleados tomó una decisión basada en los datos de la base de datos (por ejemplo, hizo un informe basado en el cual se tomó una decisión de gestión, y luego el informe de datos se basó en desaparecer), se consideró correcto eliminar estos datos.
Pero si la decisión afectó algunas acciones inmediatas con los clientes (como llamar, jugar con el saldo del cliente, etc.), todo lo que condujo a estas decisiones se mantuvo para siempre.
Puede variar de un modelo de negocio a otro:a veces, puede ser necesario registrar incluso datos internos, a veces está bien eliminar datos que afectan al mundo exterior.
Pero para nuestro modelo de negocio, la regla de arriba funcionó bien.
