On Sat, 25 Jul 2020 12:38:10 -0500
Richard Owlett <rowl...@cloud85.net> wrote:

> Back in 70's/80's I wrote programs as part of routine job duties.
>    {8080/8085 assembler, dBase and Paradox}
> Neither I, nor my employers, classed me as a "programmer".
> I was "Senior Engineering Tech" or "Junior Engineer".
> IOW, I was not in abject *AWE* of computers. *ROFL*
> 
> Right now I'm working on a personal project.
> INPUT:        How much of what did I eat?
> OUTPUT:       How much [cal/protein/fiber] did I eat?
> 
> SQL {and variants} seen to dominate all else.
> IIRC, dBase was simpler.

I think you will want SQL for this job. You will need a query with a
join of two tables. Spreadsheets really can't do that on a large scale.
I have no doubt that there are other ways (e.g. the hard way, by
programming the join code from scratch) but SQL makes that part fairly
easy. Flat-file databases are OK for trivial card-file applications,
but as soon as you want joins, you need to go relational and that
pretty much means SQL. I must admit, that after many years of dabbling,
I can still barely speak basic SQL, but that's all most simple jobs
need.
> 
> What current FOSS system might I be comfortable with?

Shame about that. If you didn't need FOSS I'd recommend Microsoft
Access, by far the best piece of software they ever produced (not that
it's a high bar). It combines a simple database server, OK for one user,
with a visual RAD system to make the user interface. Beyond doubt, it's
the quickest way to do what you want, and you can probably do most of
what you need with no code at all, just editing properties of objects.
But you have to walk the Dark Path, and pay money.

There will never be a FOSS Access, because the FOSS database people
sneer at it. A damn cheek, given the appalling state of LibreOffice
Base. I've tried to use that, but it's impossibly buggy. OK for editing
tables, now that it is finally able to talk to remote database servers
reliably and without ODBC, but disastrous for making user interfaces.
The last time I used the Report Writer (literally the last time ever) it
simply wasn't working at all, and I needed to produce an invoice
urgently. I ended up writing a PDF generator in PHP, single-purpose
certainly, just for my invoices, but it's guaranteed to work. No
software rot until PHP8...

The hard part of any database job is the user interface, an SQL database
server like MariaDb Just Works, as does SQLite. I've tried a variety of
methodologies, including CakePHP and Laravel (also a PHP framework). I
was hoping that a framework would reduce the amount of work, which they
do in some ways, but they introduce a huge amount of extra baggage. OK
if you're building something with dozens of forms and tables, or if
you're doing this every day professionally, but it doesn't help much
with simple hobby jobs. PhpMyEdit is good for really simple jobs, but it
doesn't scale well. 

I have a server, so I naturally build web applications, which are
automatically cross-platform. But I think even with a single modestly
powered computer, it's as easy to do it that way as to build interfaces
with graphics toolkits. HTML is adequate for most jobs, though *still*
missing a couple of obvious user interface features. I consider the use
of JavaScript to be an admission of defeat, but sometimes there's no
way around it. But my little netbook runs Apache2 with PHP7 and
MariaDb quite happily, for when I need to do some work away from home,
and it's trivial to copy SQL databases between servers. My first server
had 256MB of RAM, and Apache2/PHP5 and MySQL worked OK on that.

Here's how I did what you want to do: I have two main tables, the
journal and the food data. I have a third table of food categories,
which is only used as an input aid, as I currently have over 300 types
of food, which would not work well in a single drop-down list. I have a
fourth table of users, in case the application ever gets used by more
than one person.

I have three main web pages: the primary one is to make journal entries,
and show cumulative figures for single days or date ranges. it can also
edit existing entries. The next most important is for adding new foods,
which again allows editing of existing foods. There are various
databases on the Net giving nutritional values for thousands of food
types, and of course there's the side of the packet for packaged foods.
These two pages I made by hand, with a mix of PHP and HTML. The third
is a week-based statistics page, which I made with Laravel, but which
again had some hand-written PHP and HTML.

It has a few rough edges, as the programs you write for yourself never
get properly finished. I've done the 20%, I'm not willing to do the
other 80% to polish it. But it works.

Another pathway to user interfaces is either Visual Basic or Delphi, in
the FOSS form of Gambas and Lazarus. Good for making forms, but the
integration of databases is nowhere near as complete as with Access.
But it may suit you.

-- 
Joe

Reply via email to