[Discuss] Frustration with SQL and Spreadsheets

[markw at mohawksoft.com (markw at mohawksoft.com)]

> 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.