design - ¿Es un documento/base de datos NoSQL un buen candidato para almacenar un balance?
ravendb cqrs (4)
Ciertamente puedes crear un sistema así. En ese escenario, tiene el agregado de cuenta, y también tiene el agregado de período de tiempo. El período de tiempo suele ser un mes, un trimestre o un año. Dentro de cada TimePeriod, tiene las Transacciones para ese período. Eso significa que cargar el estado actual es muy rápido, y tiene el registro completo en el que puede retroceder. La razón de TimePeriod es que este suele ser el límite en el que realmente piensas sobre tales cosas.
Si tuviera que crear un sistema de contabilidad personal básico (porque soy así, es un proyecto de pasatiempo sobre un dominio que conozco lo suficiente como para evitar empantanarme en los requisitos), una base de datos NoSQL / documento como RavenDB sería un buen candidato para almacenar las cuentas y, lo que es más importante, las transacciones contra esas cuentas? ¿Cómo elijo qué entidad es el "documento"?
Sospecho que este es uno de esos casos en los que la base de datos SQL es la correcta y el NoSQL es el error, pero cuando pienso en lo poco que sé sobre CQRS y el origen de eventos, me pregunto si la entidad / documento es En realidad, la cuenta y las transacciones son eventos almacenados en su contra, y cuando ocurren estos "eventos", tal vez mi aplicación también escribe en una tienda de lectura fácilmente consultable como una base de datos SQL.
Muchas gracias de antemano.
En este caso, una base de datos relacional es la más adecuada, ya que tiene datos relacionales (por ejemplo, filas y columnas)
Como este es solo un sistema personal, es muy poco probable que tenga problemas de escala o rendimiento.
Dicho esto, sería un ejercicio interesante para el crecimiento personal y aprender a usar un banco de datos basado en documentos como RavenDB. Tradicionalmente, las finanzas siempre han sido algo muy formal, y las bases de datos relacionales se suelen considerar más formales y rigurosas que las bases de datos de documentos. Pero, como dijo, el dominio de esta aplicación está bajo su control, y es bastante sencillo, por lo que la complejidad y los requisitos no obstaculizarían el diseño del sistema.
Si fuera mi propio proyecto personal y quería aprender más sobre una tecnología nueva y ver si funcionaba en un dominio en particular, elegiría lo que fuera interesante y si no funcionaba muy bien, entonces Aprendí algo Pero tu kilometraje puede variar. :)
Personalmente creo que es una buena idea, pero estoy un poco parcial porque mi trabajo de tiempo completo es construir un sistema de contabilidad que se basa en CQRS, Event Sourcing y una base de datos de documentos.
Aquí es por qué:
Event Sourcing y Accounting se basan en el mismo principio. No borras nada, solo modificas. Si agrega una transacción que es incorrecta, no la elimine. Usted crea una transacción de compensación. Lo mismo ocurre con los eventos, no los elimina, solo crea un evento que cancela el primero. Esto significa que está publicando mucho TransactionAddedEvent.
Luego, si está haciendo una contabilidad de doble entrada, registrar una transacción es diferente de la forma en que lo ve en una pantalla (especialmente en una hoja de balance). Por lo tanto, mi gusto por los cqrs nuevamente. Podemos almacenar los datos usando los principios correctos de contabilidad, pero nuestro modelo de lectura se puede optimizar para mostrar los datos de la manera que desee verlos.
En un balance general, desea ver todas las entradas de una cuenta determinada. No desea ver la transacción porque la transacción tiene dos caras. Solo desea ver la entrada que afecta a esa cuenta.
Entonces en su documento db usted tendría una colección de entradas.
Esto hace que consultar sea muy fácil. Si desea ver todas las entradas de una cuenta, simplemente diga SELECT * FROM Entries WHERE AccountId = 1. Sé que es SQL pero todos entienden la simplicidad de esta consulta. Es igual de fácil en un documento db. Además, será muy rápido.
A continuación, puede crear un balance con una agrupación de consultas por accountid y establecer una restricción en la fecha. Observe que no se necesitan uniones, lo que hace que un documento db sea una gran elección.
Si explora un poco la teoría de la contabilidad y la historia, verá que los "documentos" deben ser los documentos fuente: orden de compra, factura, cheque, etc. Los registros contables son resúmenes estandarizados de esos documentos originales legibles por humanos. Una transacción contable es dos o más registros que afectan a dos o más cuentas, vinculadas entre sí, con equilibrio de débitos y créditos. Los saldos de cuenta, los informes como un balance o P & L, etc. son solo resúmenes de esas transacciones.
Piénselo como una arquitectura estratificada: documentos fuente, registros desequilibrados, transacciones equilibradas, y luego estados financieros.
Los documentos originales son la "fuente única de la verdad", no los registros que los resumen. Siempre debe poder reconstruir todo el db a partir de los documentos fuente. De alguna manera, el DB es solo un índice en los documentos fuente en primer lugar. Demasiadas personas olvidan esto y escriben un software de contabilidad en el que las transacciones en sí se consideran la fuente de la verdad. Esto provoca la necesidad de un sistema completo de almacenamiento y flujo de trabajo para los documentos originales, y se termina con un típico desastre corporativo moderno.
Si está trabajando con algún tipo de modelo de evento, entonces el lugar correcto para usar un evento es adjuntarle un documento fuente. El evento activa ese documento que se analiza en los registros contables correctos. Ese análisis se puede realizar programáticamente si el documento de origen ya es digital, o manualmente si la fuente es una hoja de papel o un mensaje sin formato: suena como el comienzo de un sistema de flujo de trabajo, ¿no? Sin embargo, aún desea conservar el documento original en algún lado. Un documento db parece una buena idea para eso, particularmente si es compatible con un esquema donde se pueden vincular los documentos de origen a los registros analizados y analizados resultantes, y viceversa.