[Discuss] Frustration with SQL and Spreadsheets

[Jack Coats]

SQL is a relational database from my memory.
  Who knows it could have been reclassified.  The first I remember of it
was from Iverson back 3thr 70s or '80s, HR was a INM Fellow at the time.
But I could be wrong. Oops, I remembered wrong, he did APL instead.
Chamberlain and Boyce came up with SQL but Cody did the foundational work
SQL was based on.  BTW, SQL came to life as SEQUEL initially.
 Yep, things changed a lot over my career I could keep up for years then
life happens and I could devote the time and effort.  Still a great life 😁
*><>* ... Jack

If you are not paying for something, you are not a consumer, you are the
product. - Chamath Palihapitiya
"Tell me and I forget. Teach me and I remember. Involve me and I learn." -
Ben Franklin
*Tesla Referral code: "https://www.tesla.com/referral/jack84455" - save
money on a Tesla*



On Wed, Apr 15, 2026, 9:58 AM <markw at mohawksoft.com> wrote:

> > I have worked with spreadsheet and equipment since mid'70s.  Most are
> > similar to SQL databases.  One sheet system I liked was Foresight.  Or
> had
> > formulas you could specify for given rows only or for given columns, as
> > well as row first or columns first.
>
> I worked as a bank teller right out of highschool. When I saw Visicalc on
> my old CP/M system I was so excited. It was great. I also had a clone of
> dBase on CP/M as well.
>
> >
> > SQL is better for large data, needed to be accessible by multiple people,
> > systems, programs.
>
> I have to nit-pick here. A database server is great for those things. A
> SQL database is not necessarily a server. I suggest that, if you haven't
> already, take a good look at SQLite (www.sqlite.org) it is an amazingly
> complete SQL database that can be embedded into your code. It's one of my
> "go to" technologies. It has a similar "vibe" to PostgreSQL and as a once
> postgresql dev, they share many of the same concepts and this is because
> the SQLite guys say they actively use PostgreSQL as a source of
> inspiration.
>
> >
> > I actually cut my database teeth on heirarchical databases like IBM
> IDBMS,
> > and those can emulate SQL language databasees but with less data needed
> to
> > be duplicated in each row without the overhead of multiple table pointing
> > to each other and the inherent constantly issues.
>
> No Relationas?
>
> >
> > To sum up this walk down memory lane, they all store data well, process
> it
> > pretty we6, but the trick is determining which tool is the best in each
> > case.  A rock, screwdriver and a hammer are all tools, but a rock is not
> > efficient at drevin in a screw, a hammer can too, but the screwdriver is
> > the best.  Similar story for nails, or holding down tarps.  Choose the
> > right tool for the right job.
>
> Sorry, I'm not a fan of the "right tool for the right job" analogy without
> any concrete examples to validate the analogy. I own hammers, nails, air
> tools, welders, computers, oscilloscopes, etc. I understand right tool for
> the right job.
>
> A generic spreadsheet is a user interface on a a structured data format.
> It is structured as rows and columns, just like a common database. Just
> about every single GUI created for SQL databases looks exactly like a
> spread sheet because a spreadsheet is idiomatically identical to a
> database.
>
> I imagine OpenOffice or Libre office or what ever, because of the document
> format wars 20 years ago, couldn't just switch to something like SQLite,
> but it shouldn't be all that difficult. I don't think I have ever looked
> at the code, but one hopes that the data file format is sufficiently
> isolated from the rest of the app.
>
>
>