Path: ...!weretis.net!feeder9.news.weretis.net!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!nnrp.usenet.blueworldhosting.com!.POSTED!not-for-mail
From: "Edward Rawde" <invalid@invalid.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Serial, concurrent, parallel
Date: Fri, 17 Jan 2025 07:19:31 -0500
Organization: BWH Usenet Archive (https://usenet.blueworldhosting.com)
Lines: 64
Message-ID: <vmdhsl$30jh$1@nnrp.usenet.blueworldhosting.com>
References: <vm69a2$2h52d$1@dont-email.me> <vmam6l$3et7s$1@dont-email.me> <vmar9r$3g1ud$2@dont-email.me> <1r695ej.t31qiz7lhsjkN%liz@poppyrecords.invalid.invalid> <vmb2ko$3hal6$1@dont-email.me> <1r69dpn.1bbzdc81ozzc9wN%liz@poppyrecords.invalid.invalid> <vmbh9o$14pn$1@nnrp.usenet.blueworldhosting.com> <vmc36h$3mt5f$1@dont-email.me> <vmcluq$2drc$1@nnrp.usenet.blueworldhosting.com> <vmctge$3u72f$1@dont-email.me>
Injection-Date: Fri, 17 Jan 2025 12:19:33 -0000 (UTC)
Injection-Info: nnrp.usenet.blueworldhosting.com;
	logging-data="98929"; mail-complaints-to="usenet@blueworldhosting.com"
Cancel-Lock: sha1:lWIj26e7v0wWkIqmtLIfi+QfEO0= sha256:O6VfNO/80ZQ4/O6DX2qAP2ohTw0hz1y3ltfIYc0izus=
	sha1:I60kr36vMjWEiJ7FueUe9PtSll4= sha256:lD1RykvCW50b8W+ix1qMPDUdV5pkKAMGRPXQweiqQAk=
X-RFC2646: Format=Flowed; Response
X-MSMail-Priority: Normal
X-Priority: 3
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
Bytes: 4507

"Don Y" <blockedofcourse@foo.invalid> wrote in message news:vmctge$3u72f$1@dont-email.me...
> 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 may as well ask what it looks like when a jpg is opened in a text editor.

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