> On Aug 8, 2022, at 10:53 AM, Robert Simmons <rsimmo...@gmail.com> wrote:
>
> Understood.
>
> After looking under the hood a good bit as well as thinking about the
> problems of accounting and databases in general I have a side question:
>
> If you're working on a rewrite of some kind, why not use a graph database
> as the back end rather than SQL?
>
> The reason is that a graph database seems to me to be a very natural choice
> for this type of data. A transaction has an amount, so that amount is a
> node. A transaction also has a source and destination, and edges in a graph
> database can only connect two nodes. They also can optionally have
> directionality.
>
> Also, graph databases solve the problem of welding on new stuff later on
> down the line.
>
> SQL seems archaic. Why not drop it completely if you're working on a from
> the bottom up change?
https://en.wikipedia.org/wiki/Graph_database#Comparison_with_relational_databases:
"relational database management systems are typically faster at performing the
same operation on large numbers of data elements".
Accounting systems primarily perform the same operation on large numbers of
data elements.
Regards,
John Ralls
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
