In the earlier Source Documents column, we said, "With the computer, it really doesn't matter whether you record your transactions in ordinary text files and use programs or "scripts" you write to use the data — or with the spreadsheet or database tools you may already be familiar with — or with full-fledged "accounting packages".
From the preceding retail-recordkeeping discussion, it's obvious I prefer the text file and script approach. While I still have your attention, I'd like to explain why.
My approach, from my first computer, has been to set up my business systems on computer exactly as I would set them up manually — except that any records I would compile on paper in a manual system, I would compile instead in a computer file (and one looking much like the paper record). This got the "essential" data into the computer — whereupon I could write "scripts" to use the data in the ways I wished.
In the early days, when computers weren't particularly reliable and I wasn't particularly secure in my approach, this had the advantage that I could run the manual system and the computer system in parallel while I gained confidence — and I could always switch back to the manual system if things went badly wrong. But the approach proved versatile and powerful, so I've stayed with it — despite the flood of software tools and packaged software that others have offered to "solve" these problems.
To use this approach, I had to learn a "scripting" language. Scripting is simplified programming. (There are probably some programmers who would argue with that.) Scripts are "interpreted", i.e., run directly — you write into a file what you want the computer to do. You run the file. It either does or doesn't do what you want. If it doesn't, you go back into the file, change something and try again. And you keep changing and trying until it does what you want.
Programs, on the other hand, are "compiled" — there's a (quite lengthy and complicated) compilation step between your changes and your trys. In addition, programs need more "details". You need to declare on the front end what variables you're going to be using, how you want each variable represented ("integer", "floating point", "double-precision floating point", "string", ...), etc.
Scripting languages take care of all that mickey-mouse for you. (In fairness to programs, they're more powerful, more versatile and run faster than scripts. However, if scripts do the job you're looking to do, their simplicity and user-friendliness — especially to a cut-and-try programmer — make them the way to go).
Note: Any good programmer would find "cut and try" programming abhorrent. But, hey, I'm not a "programmer" — I'm just trying to get a job done. 80-90% of the time that goes into the writing of a "professional" program is in making it "robust" — i.e., if the user mis-uses it, it will still yield sensible results. But I don't give a damn about that. I have enough redundancy built into my systems that if I screw something up, or forget something, I'll catch it — and when I catch it, I'll fix it. Professional programming and "cut-and-try" scripting are two very different animals — and the latter, anyone can do.
There are many good freeware scripting languages available — awk, perl, python, etc. Even the most primitive — awk, which is what I use — enables you to do anything with textual (i.e., alphanumeric) data. If you keep your data as readable text, awk can do anything you want with that data.
And even awk is overkill for our purposes. I dare say I've never used more than 10-20% of awk's capabilities. (I sorta know those capabilities are there and every once in a while, I'll run into something that seems particularly awkward to do with what I know, so I'll play around with some of those unexplored capabilities until I find a better way of doing what I need — and, voila, I'm using one more capability of the language.)
Now, after watching the time people spend learning the popular spreadsheet or database tools — and/or accounting packages — I'm convinced they'd be far better off just sitting down and learning a simple scripting language. It would take a fraction of the time — the way to learn a scripting language is to just start using it to try to do things you want to do — and, once learned, gives you far more versatility and capability than those other tools and packages — that take far more time to learn.
End of soapbox.