Re: Serial, concurrent, parallel

On 1/16/2025 5:03 AM, Liz Tuddenham wrote:

Don Y <blockedofcourse@foo.invalid> wrote:
 

... Especially as so many people seem to use spreadsheets
in lieu of (real) databases.  :<

 As far as I can see, a databse is just a spreadsheet that has been
crippled by having all the cells on each line tied together

Databases (relational ones) are *so* much more.  In addition to
strict typing on each "column", you can define relationships
between columns and specific values in columns, writing code
to enforce constraints so that certain values are not accepted
in certain places based on other values, etc.
E.g., I can state that "fertile" can not be true if "sex" is not "female".
On a per-record basis.  So, Bob can never be marked as "fertile" but
Becky might!
Or, that the city can not be "chicago" unless the state is "Illinois"
(I am assuming there are no chicagos in other states; "Springfield"
tends to be a popular city name -- but, there is no Springfield in
Alaska so if someone tries to enter an address of Springfield,
Alaska, it is known to be invalid and shouldn't be accepted.).
Or, that a social security number must be of the form XXX-##-####
*and* XXX can't be 000, 333, 666, etc.
Or, that a mother's birth date must precede those of her biological
children by at least 5 years but the father's must precede his
biological children by 9 years.
Etc.
And, I can ensure data is not accepted (by the database) if those
specific conditions aren't met.
I can also issue an upcall when certain constraints are met or violated.
I can have a billion records, easily accessed (indexes), each with
1000 plus columns.  And, of course, tie as many of these "tables"
together as if one larger entity (1:1, 1:N, etc.).
E.g., I don't support "files" in my system as then EACH consumer would
have to either assume they were intact and of the correct format *or*
verify their contents prior to using them.  Instead, I use "tables"
(relations) and let the RDBMS ensure everything is correct.  So, an
application doesn't have to parse the syntax of a particular file and
verify particular "parameters/data" are correct; instead, it can use
them directly on the assurances of the RDBMS that it would only
ALLOW valid data AND would *maintain* that so the application doesn't
have to verify everything is "still" OK.
If some CONCURRENT client opts to change a record (assuming he has
permission to do so), I can notify other clients of the change so
they don't have to sit and poll the data for changes (e.g., make
a whiteboard or publish/subscribe service).  All the while ensuring
that the changes made retain data validity.
I can change multiple records in a single "transaction" such that
if some other (concurrent) client tries to access any of that at
the same time, he doesn't see partial results (atomicity).  Or,
roll back the entire transaction as if it never happened.
I can store firmware for my devices as fields (BLOBs) in a table.
E.g., create tuples like (ModuleType, FirmwareImage, Revision)
and then just issue a query:  "I need the greatest Revision number
of FirmwareImage for a particular ModuleType").  If newer firmware
becomes available for a particular ModuleType, the *database* will
signal the applications that use that firmware of that new version
so they can be updated -- the user doesn't have to know what
goes where, etc.
SWMBO tracked the capital expenditures for a local hospital for
many years.  The "Finance" people thought in terms of spreadsheets.
So, any time top management wanted to know "how much did we spend
on *paint* for the east wing renovation and how much was the associated
labor cost", they would have to find the "paint" entries and then
try to sort out which labor charges were associated with "painting".
SWMBO would write a query and have the answer in a few minutes.
Because ALL of the costs were in one place, not scattered around
multiple spreadsheets.  Just qualify the results for "Project = East
Wing Renovation"
She has been tracking our household expenses with the same set of
tables.  So, when we have to decide what level of membership we
should purchase for Costco (a "members only" store where different
classes of membership have different costs and "rewards"), she can
identify how much we spent there, in any given year.  As a first
order approximation, we can then see if the end-of-year "rebate"
associated with the membership class will cover the added cost of
that membership class.  AND, can further refine that by spitting
out the big ticket items that we may have purchased in that year:
"How likely are we to purchase ANOTHER set of tires THIS year?  If
not, then our expenses will likely be $1000 less and the rebate
proportionately so!"
I use a set of tables to track all of the files on all of my disks
(including files inside "archives", VHDs, VMDKs, etc.).  So, if
I am looking for something, I can type a query and see which media
are likely to contain the file(s) desired.
I can also use this to tell me if there is another copy of a particular
file, elsewhere (same size and hash -- even if the NAME is different!
Try doing that for just ONE computer, with a spreadsheet.  E.g., THIS
computer (with just WWW browser, MUA and a few token apps) currently has
302,146 files in 35,180 folders.  And, that doesn't count any of the
files *inside* ZIP, CAB, TGZ, etc. archives that appear "once" in that
count.
How would you do this with a spreadsheet?  N columns for the N files
that might be *inside* a particular file?  Isn't it easier to:
      ID
      Name
      ID of Container
and let the query build a full pathname, *if* you need it:
      ...
      (5, "C:", 0)
      ...
      (9, "Windows", 5)
      ...
      (45, "notepad.exe", 9)
to encode:
      C:\Windows\notepad.exe
My "address book" tracks family relationships.  So, I can ask for
a list of my uncle Joe's kids' *spouses'* names.  How would you
address that in a spreadsheet -- some large number of column-PAIRS
that, hopefully, exceed the largest family size for each
child+spouse?  And, their birthdates?  Phone numbers?  Addresses?
Photos?
Isn't it simpler to have:
     ID of person
     First Name
     Last Name
     ID of mother
     ID of father
     Birthdate
     ID of spouse
     Address
and let the query *build* the family tree by resolving each of these
"IDs" *in* the query?
And, as there are likely fewer addresses than persons, maybe track addresses
in a separate table and just link to an "ID of address" for each person?
As there are a finite number of City names, maybe a "ID of city" in the
address table?  Ditto for "ID of state"?
Of course, you don't need to *see* all of these "linkages"; the query
hides them and just shows you how they *resolve* (a City ID of "327"
means "Riverside")
IMO, people like spreadsheets because they can "see" all the data.
So what?  Can you spot any that is bogus?  Missing?  Duplicated?
If there are 302K rows, how long for you to scroll through them all?