LWN: Comments on "Coming soon: KMyMoney 1.0"

Coming soon: KMyMoney 1.0

sciurus — Sat, 29 Aug 2009 03:35:57 +0000

Anyone looking for personal finance software should try Homebank. Great interface, great features, GPL, license and it runs on GNU/Linux, FreeBSD, Microsoft Windows, MacOSX, Nokia N*** and Amiga.

Coming soon: KMyMoney 1.0

dlang — Fri, 28 Aug 2009 16:48:06 +0000

one advantage to manipulating things in SQL rather than in a flat file is that you don't have to worry as much about the structural elements (field seperators, allowed characters, field lengths, etc) as the app can (and should) have this data managed by the database engine.

Coming soon: KMyMoney 1.0

jordanb — Fri, 28 Aug 2009 16:43:24 +0000

One thing to keep in mind about sqlite is that the 'database' is just a file on the file system, and you can use the 'sqlite3' tool to open up and poke around in any sqlite file.

Actually if you're trying to manipulate the data 'out of band', or make an external tool that acts on a program's data, then sqlite is a dream format since it gives you a very powerful structured data manipulation interface (the SQL language).

If you want to keep the data in version control, you can do a data dump from the database file into a text file and then check *that* into VCS:

echo ".dump" | sqlite3 grampsdb > my_gramps.sql

You can also do that, of course, and use your regex masher on that sql file, and then import it back into the database. ;)

Coming soon: KMyMoney 1.0

dlang — Fri, 28 Aug 2009 16:23:52 +0000

I see the biggest is the data safety issue

when making a change (no matter how trivial) you would need to write a modified version of the entire file and do the appropriate fsyncs (for the file and the metadata)

with a database you just tell the database what changes you want done and it makes the changes (probably fare more efficiantly than you will, as well as being far less likely to have missed some corner case)

searching a xml text file involves reading the file, parsing it, then walking the data in memory (or reading the file, parsing it as you go, and aborting the parsing when you have the data you need)

databases have many tricks that they can use to speed the data access (indexes, binary data representation, etc)

as for locking the data in a 'hard for the user to use' format, I would say that putting it in a standard database that many different tools can readily access (in many cases making it look like a spreadsheet, but including dump/restore to/from flat text files) makes it pretty easy to get at the data.

also, keep in mind that one commonly used database for this is sqlite. that database engine keeps all the data in one file (just as easy to check into a version control system), and does not require communication to a seperate daemon. it basicly acts as a file manipulation library in your software, so it has very low overhead.

as for redundancy and failover, that can mean many things. if you want to have the data stored on a central box (rather than sitting on someone's laptop that can break, get lost/stolen, etc) databases can do failovers to backup boxes transparently to the user

for a single home user this (usually) does not matter, for a small business this can be critical.

In addition, with a database back-end it is relativly easy to allow multiple people to share access to the data at once. again, not a feature that a single home user normally cares about.

Coming soon: KMyMoney 1.0

astrophoenix — Fri, 28 Aug 2009 15:29:46 +0000

interesting. I see what you're saying. it makes theoretical sense.

but I wonder where the crossover point is: i.e., how big does your dataset have to be before a user using the gui app will notice any difference between a database backend or an xml backend?

because the other tradeoff is that it's a LOT simpler for a USER of the data to do unexpected things with the data if it's ascii.

I suppose I could just export it to the ascii, do what I want with it, and then get used to the routine of importing it back from the ascii each time I run the gui app.

before I was really thinking about the tradeoffs, the idea of a Free software project putting the data in a hard-for-the-user-to-use format seemed a bit jarring; technically the database format is still useable, but getting database redundancy and failover is a tad bit more work and more fragile than committing a text file to git or mercurial.

Coming soon: KMyMoney 1.0

dlang — Thu, 27 Aug 2009 23:57:46 +0000

using a database instead of a flat file will be far safer and faster to update.

you can implement all this yourself (but not easily in a ascii xml file), but at that point you have duplicated the hard stuff that a database does.

once you take the effort of converting your software to work with a database (delegating the data integrity, searching, indexing, etc tasks to the database) with an embedded database like sqlite, it's a small step to move to a full database that can offer you additional features (like replication and failover) for no additional application complexity (beyond the change to talk to that sort of database)

the application should have the ability to do import and export through flat files, but it makes a _lot_ of sense to use a database instead of flat files (and especially instead of ascii XML files) for the main datastore.

Coming soon: KMyMoney 1.0

astrophoenix — Thu, 27 Aug 2009 23:01:34 +0000

what in the world is the big move to database backends? I like having the data stored in an ascii xml file...

'gramps' has already moved to a database storage model, and I hate it. I liked doing crazy ascii type stuff with the data, like being able to read it! or tweak stuff by hand occasionally. or manage it using git or mercurial. now if I simply open gramps, then close it, I get a bunch of binary changes that are meaningless; I didn't actually change any data.

can anyone explain the advantage of using a database instead of an xml file for something like a personal accounting app??

frustrated, and loving ascii,
astrophoenix

Coming soon: KMyMoney 1.0

jospoortvliet — Sat, 22 Aug 2009 09:51:11 +0000

How about those? There is nothing which makes KDE apps not work in
Enlightenment or any other environment... The only two things about KDE
apps are the development platform and the community. In every other area
they're just applications which can run anywhere - from win and mac to KDE
and Gnome...

Coming soon: KMyMoney 1.0

jhhaller — Fri, 21 Aug 2009 18:46:08 +0000

Much of the recent buzz about platforms has been on Mobile applications. While desktop application may be good for the analysis and data storage, that without a mobile interface that much of the market may pass by this type of desktop application. Much of the discretionary spending happens outside the house, and carrying a laptop outside the house is a problem, especially when multiple people in a house are making independent decisions. At the very least, a mobile web interface to limited parts of the data would make it more useful.

Coming soon: KMyMoney 1.0

morhippo — Fri, 21 Aug 2009 18:34:02 +0000

You need to install one additional library (kdelibs) and that's it. Stop complaining.

Coming soon: KMyMoney 1.0

golding — Fri, 21 Aug 2009 08:03:58 +0000

What about those of us who do not use KDE? Or Gnome for that matter?

I use Enlightenment without Gnome and GnuCash still seams to be best fit.

OFX Working Well

hisdad — Thu, 20 Aug 2009 05:10:57 +0000

I switched from the .8 series to the .92 version to the CVS version to enjoy the use of OFX. That's well supported here in New Zealand. One of the best features is Payee Matching. This lets me use my Payee name in Kmymoney and match transactions coming from the bank.

It makes things easy that previously were so tedious.

Budgeting is good, with a flaw if your fiscal year is not a calendar year, it truncates the budget.

Excellent piece of work.

--john