Re: Serial, concurrent, parallel

On 1/16/2025 9:22 PM, Edward Rawde wrote:

"Don Y" <blockedofcourse@foo.invalid> wrote in message news:vmc36h$3mt5f$1@dont-email.me...

On 1/16/2025 10:57 AM, Edward Rawde wrote:

Databases can also be backed up as human readable text files.

>
To be fair, a spreadsheet's contents can similarly be exported (CSV).
I'm not sure how the formulae, formats, etc. are handled, though.
And, any non-text entries (that might be supported).

>
In other words exporting a database as SQL is not in any way similar to exporting a spreadsheet as csv.

>
Of course it is.  The difference lies in WHAT you are exporting.
What does a 3MB photo (stored as a BLOB) look like when exported in SQL?
Is it any more recognizable in that form?

>

You might be better off unzipping the xlsx and parsing the xml if you really want your spreadsheet elsewhere.
>

>

Just export data as SQL.
This gives me peace of mind that whatever software is or isn't available in the future I can always read my data.

>
The value of SQL as a "dump" format is that you can *import* it into
another SQL DBMS -- as long as the recipient supports the same (or
greater) level of features.  And, the import process is nothing more than
piping the dump file to the recipient DBMS's "console" as it consists
entirely of SQL commands.

>
I frequently paste an entire SQL dump into the Query tab in HeidiSQL.

>
My dumps tend to be too large to cut-and-paste.  Instead, I just
pipe them to the console (or, tell it to "read input from file").
>
Of course, this assumes everything will work well.  If the shit hits
the fan when you are 5MB into restoring/moving a 25MB dump, recovery
can be difficult; how much of the dump was accepted?  why did it
abend?  how can I use what HAS been accepted while adding to it
the portions that have not?
>
That's no worse than a spreadsheet import that abends; what recourse do you
have, there?  Manually inspecting all the cells?
>
The drawback with databases is that there is a non-trivial skillset
to be learned to make effective and efficient use of them.  You not
only need to learn another programming language (or three), but,
also, need to think about how the data is organized and stored
vs. how you will want to access it.
>
E.g., why not store everything as a TEXT field?  What value the added
costs of BPCHARs over TEXTs?  How to store an imprecise date/time (e.g.,
if you know a person's birthdate is:  "in september", "in 1970", "on
march 15", etc. but don't have a COMPLETE date to store)
>
What form of index(es) should be supported?  And, on what field(s)
(or combinations thereof)?
>
Extra credit:  what's the best way to store MD5 hashes?  And, why?
>