Re: Serial, concurrent, parallel

On 1/17/2025 2:36 AM, Liz Tuddenham wrote:

You appear to be conflating the actual storage systems with the ways of
getting access to them.  All the things that you like about databases
could equally well be done with spreadsheets

No, you can't.  You would have to change what it means to be
a spreadsheet by augmenting their functionality to the point where
they *became* DBMSs.

- it's just that database
access software manufacturers have tailored their products to particular
needs whereas spreadsheets haven't attracted the same attention.
 Fundamentally, spreadsheets are just the same as databases but without
the constraints of the cells on each line being tied together.  To put
it another way: a spreadsheet is a non-relational database.  The
software to manipulate them, which is what you have been describing, is
a totally different matter.

No.  A spreadsheet is just a grid of cells.  The data in one cell
can have entirely different meaning than the data in the cell below
it.
I can create 10 small, unrelated "spreadsheets" on a single spreadsheet
"page".  One can occupy the area bounded by A1 and C25 -- 3 columns, 25 rows.
Another A40 to D57 (4 columns, 18 rows).  Another from B26 to G38
(6 columns, 13 rows).  And, another from E1 to L10 (8 columns, 10 rows).
I.e.,  rows 1-18 pass through two DIFFERENT "spreadsheets".
Column A does, as well.  Column B passes through *three*.
The contents of each of those columns and rows in different
spreadsheets need not be related or even of the same data
types.
Furthermore, within a single of those "(mini)spreadsheets", the
type of data in one row need not be related to the type of data
in the row that follows it, EVEN IF PART OF THE SAME SPREADSHEET.
In a database, rows are *records* that are treated as units (tuples).
Columns are fields that have a single *defined* datatype that is
enforced by the DBMS.
If you want to have the equivalent of mini-databases in a DBMS,
then you have to create (and define) mini tables (relations/tuples).
Each will have a row 1 and column 1 -- but, they will be totally
unrelated in data type and size/length.
E.g., my Cities table lists all of the names of the cities
found in any state/territory in the US.  The States table
just lists the names of states/territories.  Entirely different
lengths and meanings to the data.  The Localities table
contains pairs of (city, state) identifiers (the identifiers
defined and mapped to specific cities/states by those
respective tables).
You can TRY to build a spreadsheet that LOOKS like this.
But, it won't GUARANTEE that the identifiers for the city
(and state) defined for "locality 1" are valid city (and
state) identifiers.  This doesn't just apply to entering
the data but, also, modifying it and deleting it!
E.g., if you try to *delete* the city "Chicago" from the
city table, the database won't let you -- because there
is a locality that references it:  (ChicagoID, IllinoisID)
I can augment the State table with a "Capital" table;
it contains the ID of the City that names the capital
of that state.  Again, the DBMS won't let me pick
a city that doesn't exist in the city table.  And,
it won't let me pick a city that isn't named as a locality
*in* that state (because that would imply that it was ALSO
a locality -- why not named as such?)
The DBMS will enforce rules as to which "roles" can perform
which actions on which tables.
It will also ensure that multistep operations all happen
as an indivisible (atomic) "transaction" so no other
user (accessing the database at that same instant)
will ever see "partial results".  E.g., adjusting the
population of locality 5 down by 321 souls to reflect the
folks who have RELOCATED to locality 88 (you will never
see 321 *extra* people nor 88 *fewer* people, depending
on the order in which the *individual* population counts
were "adjusted".)

Spreadsheets allow you to move columns and cells around individually -
which is a very dangerous procedure if the spatial relationship between
the cells is key to the information being stored.  Databases are safer
in this respect but less versatile if your data is the type which does
not depend on cell position in a table.

"Position" is a partial constraint in a DBMS.  ALL the data in a
particular column (field) is of the same type and has the same
constraints applied to it.  You wouldn't want someone to be able
to move a "birthdate datum" to an "account balance" column (field).
WHERE the column sits is immaterial, relative to the other columns;
I can move the birthdate column to column 4 or 8 or 87.  But, there
will never be any "empty/undefined" columns between existing columns!
Similarly, fields in a row have a RELATIONship to each other.
The population of locality #1 is specified in THAT row -- not
in the row associated with locality #33.  WHICH "physical"
row doesn't matter but it is treated as a coherent unit.
Again, no "empty" rows -- unless they are intentionally
defined to contain "all NULL" data (which means they are not
empty but just "full of NULL")
DATA is of the utmost importance in a database.  It's integrity,
access, "role", etc.
Spreadsheets are just "scraps of paper" with no constraints on
what happens, where.  Just like one can doodle in the margins
of a sales receipt -- those doodles having nothing to do with
the purchase described by that receipt.
Many spreadsheet products are inherently "visual" -- owing to
the emphasis the developers placed on that aspect of the UI.
By contrast, most (serious) DBMSs are not; one relies on
some other tool to give the user a GUI.
Because (serious) RDBMSs have a standardized definition language,
one can build such a tool and apply it to a variety of DBMSs.
E.g., I can draw an Entity Relationship Diagram (ERD) that
shows how a set of tables are /(inter)RELATED/.  This can
be used to define -- and link (join) -- those tables in a
yet-to-be-selected DBMS as their "code generators" implement
the same mechanisms regardless of RDBMS.  With that knowledge,
the tool can provide a spreadsheet-style "table" to enter
data -- even if the individual data end up being distributed
to several different tables, in the process.  Or, sort the
PRESENTATION of the rows in these conjoined tables -- even
though the actual data in the DBMS isn't "moving".
Spreadsheets emphasize *these* features, at the expense of the
data's integrity.