Rationale Revisited

I was thinking more about my reasons to embark on this project, and thought I would get them down on... err... paper? Well, somewhere.

I was reading a page that was discouraging the use of proprietary binary formats. That sounds a lot like what I am saying, but it's not quite the same. That same page lists some alternative open-source packages for personal finance. The problem is, I am still locked in to a single program. Sure, I can move my data around easily, but heck I can do that with Quicken my current package, too. I want to have my data accessible from a variety of programs and scripts without having to export and import data.

As an analogy, consider HTML. I use BBEdit a lot for editing raw HTML. But I also use TextEdit. And, until the UI drives my batty, Nvu. And sometimes I'll whip out a Perl script to process my documents. I've even used Visual Studio to edit HTML, and I will often use more than one editor at the same time. My choice of data storage (HTML) does not dictate my choice of editor. That's the power I want with my financial data. Now, I could just stick it in a text based format, but a database offers me options for searching and relating data that are hard to duplicate with text formats (though not impossible). Where HTML is SGML with added rules, this will be a SQLite database with added rules. The fact it is binary just means you will have to use different editors to read and modify it. It would still be perfectly possible using existing tools to create and modify your financial data, just like you can with HTML. And just as easy to screw it up.