¿Es una buena base para documentos/bases de datos NoSQL para almacenar un balance?

Question

Si tuviera que crear un sistema de contabilidad personal básico (porque soy así, es un proyecto de pasatiempo sobre un dominio que estoy lo suficientemente familiarizado para evitar empantanarme en los requisitos), una base de datos NoSQL/documento como RavenDB ser 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 eran en realidad una base de datos SQL es el sistema más adecuado y tratando de ir NoSQL es el error, pero cuando pienso en lo poco que sé de CQRS y abastecimiento caso, me pregunto si la entidad/documento es realmente la cuenta , y las transacciones son Eventos almacenadas en su contra, y que cuando ocurren estos "eventos", tal vez mi aplicación también escriba en una tienda de lectura fácilmente consultable como una base de datos SQL.

Muchas gracias de antemano.

Answer 1

En este caso, una base de datos relacional es la más adecuada, ya que tiene datos relacionales (por ejemplo. Filas y columnas)

Dado que esto es sólo un sistema personal, que son altamente improbable que tenga cualquier escala o el rendimiento cuestiones.

Dicho esto, sería un ejercicio interesante para el crecimiento personal y aprender a utilizar una base de datos basada 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 acerca de una tecnología nueva y ver si funcionaba en un dominio particular, iría con lo que fuera interesante y si no funcionaba muy bien, entonces aprendí algo. Pero tu kilometraje puede variar. :)

Answer 2

Sin duda puede crear un sistema de este tipo. 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 la carga del estado actual es muy muy rápido, y tiene el registro completo en el que puede ir hacia atrás. La razón de TimePeriod es que este suele ser el límite en el que realmente piensas sobre tales cosas.

Answer 3

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é:

abastecimiento de eventos y Contabilidad 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.

A continuación, si realiza una contabilidad de doble entrada, registrar una transacción es diferente a 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 puede optimizarse para mostrar los datos de la manera que usted desea verlos.

En una hoja de balance, 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.

De modo que 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.

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.

Answer 4

Si explora un poco la teoría de la contabilidad y la historia, verá que los "documentos" deberían ser los documentos originales: 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 cuentas, los informes como un balance o P & L, y así sucesivamente son solo resúmenes de esas transacciones.

Piense en ello como una arquitectura en capas: documentos fuente, registros desequilibrados, transacciones equilibradas, y luego estados financieros.

Los documentos de origen son la "única fuente de 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 de origen. 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.