[Discuss] Frustration with SQL and Spreadsheets

[markw at mohawksoft.com]

> On Wed, 15 Apr 2026 08:21:43 -0400
> markw at mohawksoft.com wrote:
>
>> One of the things I have to do a lot is transfer data to and from
>> spreadsheets. Its so frustrating that they are essentially the same
>> concept: an X/Y grid of cells is virtually identical to rows and
>> columns.
>
> This is not a valid premise. A spreadsheet has infinite rows and
> infinite columns. A SQL table has infinite records (rows) of *finite*
> columns.

Not really, well first, spreadsheets have a practical limit to how many
columns they can have. Excel, for instance, I believe have a limit of
16,384 columns. SQLite3 has a defined maximum number of 32768 of columns.

Excel is limited to 1048567 rows, and sqlite3 s functionally unlimited.

You can add and drop columns in a table on SQL.

>
> Here's a contrived example: an address book. You have columns labeled
> first name, last name, email address, phone number, street address. In
> the spreadsheet version you can add extra columns to a row for ZIP
> Code, an alternate email address or phone number, etc., without
> affecting any other rows. You can't do this in the SQL table version
> because the structure of each record (row) is fixed to first, last,
> email, phone, street. You would have to refactor your database schema
> to accommodate the new columns and rebase your data to fit the new
> record format so that every record in the table now includes the new
> columns.
>
> This is a simple example. I'm sure a SQL DBA could tell you all about
> how relational tables and pivot tables and all that stuff work, and why
> trying to represent those structures as spreadsheets is going to be a
> big mess.

I'm not sure I accept your example at all. If you add a column to a
spreadsheet, you add that column to all the rows. The same as a database.
What am I misunderstanding? if you shift a cell left or right you "break"
the columnar relationship of the datum. Just as you would a sql database.

I need a better example. Are you talking about having to populate the
entire added column? That's not nessisary, most databases have abandoned
the "fixed row length" indexing decades ago. Generally speaking, most
databases have a table definition that they edit and cells can be NULL.
Adding a column is basically editing the table definition.

>
> Or I could just point out that Microsoft have never implemented a "Save
> as Excel" function for Access despite the nigh-infinite requests for
> one.

That is a different statement. Saving a database as a spreadsheet could be
a loss of data. Saving a spreadsheet as a separate database system may
also lose data. Implementing a spreadsheet on top of a database need not
do that.