Re: [Interim Solution] Re: FOSS equivalents of *OLD* database and spreadsheet tools?
On 7/29/20 06:03, Richard Owlett wrote:
> On 07/29/2020 06:13 AM, Joe wrote:
>> [snip]
>>
>> I'd recommend using the right tool for the job.
>>
>
> Which is why I'll investigate.
> Your approach is literally orders of magnitude more than I want.
With respect, Joe is right, in my opinion based on some about 20 as a
DBA and later head of the database branch in a DOD agency.
I quite understand what you are proposing, and over the years the branch
spent a good deal of time and taxpayer resources sorting such
applications developed by accountants to help them in their work. Over
time they grew big and complex beyond their original simple design,
scaled and performed poorly, became infected with data (and formula)
errors that the developers could not fix. All too often the developers
had retired or otherwise moved on and their successors, who had little
understanding of the application beyond its use, were completely at a
loss. It was a mess, and around the time I retired, we did an agency
wide search and found around 500 of them, quite a few critical to
accounting operations yet largely undocumented and often seriously at
variance with accepted accounting rules and standards. The projected
cost of cleaning up was mind-boggling.
Many of those concerns, of course, do not apply to a relatively small
dietary application like you are considering (but consider Joe's size
metrics). A number of them do.
1. Lack of documentation. It takes a lot of discipline to document any
application even to the point where the developer, after a few weeks,
can easily identify its organization and fix or extend it. That is more
difficult with a set of spreadsheets than with a proper relational
database where the defining statements go a considerable way to
documenting themselves.
2. Errors. A decently designed relational database will present fewer
opportunities to insert data errors and make them easier to find and fix
when they do creep in.
3. Work involved. It is entirely possible to design a relational system
based only on CSV or other flat files; Unix, and I suppose Linux even
provides commands for most or all of the fundamental processes, and
desktop machines no more than a decade or so old can perform reasonably
well for small and moderate size databases and straightforward queries,
although performance will fall fairly rapidly with size and complexity,
and designing queries is harder and more labor intensive and error prone
than using a tool - SQL - designed for the job.
I have not looked at recutils, and my opinion is not necessarily worth
much as far as they are concerned. That said, I think it is unlikely
that the learning curve would be lower or less steep than with a proper
DBMS. My preference in a Linux environment is Postgres, but MariaDB and
SQLite are quite up to the task. Any of them can be installed with a
single command, and at least one probably already is installed. Their
configuration for basic use is not difficult, and there are ample web
based and probably public library based sources of "howto" information.
You are the best judge of your situation, but the notion that setting up
and using a proper database is "literally orders of magnitude more than"
a utility based alternative almost certainly is rubbish; it is, at
worst, only slightly more, and the benefits are substantially more.
Regards,
Tom Dial
Reply to: