Can anyone suggest a simpler "real world" problem to promote these "situations/scenarios"?
Imagine, instead, someone (sous chef?) running out to BUY some potatoes
for the meal and:
- coming home empty handed ("they ran out of potatoes")
Don Y <blockedofcourse@foo.invalid> wrote:
Can anyone suggest a simpler "real world" problem to promote these
"situations/scenarios"?
Yes, good cooks do it all the time.:
Put the kettle on to boil water because you can't do anything until you
have boiling water. Work out what is going to take longest to cook (potatoes) and put them on first.
Cut up the meat and fry it while the
potatoes cook but as soon as it is in the frying pan, put a saucepan of
water on the hob to bring it to the boil.
While the water is coming to the boil, start cutting up the green vegetables.so they are ready when the water boils. With 10 minutes to
go, put in the vegetables and, with luck, the whole meal will be ready
to serve at the same time.
I had a friend who used to cook serially. Her fried eggs had been
sitting cold and rubbery for 15 minutes by the time the bacon was ready.
For a while she cooked for a lodger - on one occasion he sneaked out and bought himself some fish and chips, ate them in his room and went to
bed. She was very upset when she called him down for his evening meal
and found he wasn't hungry and had been asleep for over half an hour.
Don Y <blockedofcourse@foo.invalid> wrote:
Imagine, instead, someone (sous chef?) running out to BUY some potatoes
for the meal and:
- coming home empty handed ("they ran out of potatoes")
I have had a similar scenario when cooking for two of us in my van for
12 days. My companion was in the early stages of dementia and things
kept going 'missing', only to turn up next day in the most unexpected
places. That included items of food, so changes to a planned meal had
to be improvised as I went along and I had to always bear in mind what
to do if something we had bought for supper just wasn't there when I
needed it.
Although cooking on a one-burner diesel stove in the back of the van is
a serial affair, it mimics a parallel one when several different items
have to be heated up or kept hot at once. I sometimes found I was
literally operating my hands in parallel, getting ready to take
something off the stove with one hand whilst preparing the next item to
go on it with the other - then a quick swap-over.
I am surprised (disturbed?) at the problems people seem to have
sorting these things out in their thought processes. I don't
*believe* people think strictly "serially" but I am beginning to
question that belief as I witness smart/capable people stuck in
that mindset!
I've been finding problems with their implementations that
would not be present if they TRULY "thought in parallel". Things
that should be obvious seem to slip right past them. This came
to a head when I asked a colleague to explain multitasking:
"Well, FIRST, the processor does... and THEN..."
"Ah, 'THEN'! So, you are thinking about multitasking as the
SERIALIZATION of multiple tasks instead of the CONCURRENT
execution of them! So, when your code is run in true parallel
form (multiple cores, multiple processors), all of those hidden
assumptions that you've baked into your design fall apart because
they are no longer implicitly serialized!
Can anyone suggest a simpler "real world" problem to promote these "situations/scenarios"?
On 1/14/2025 2:12 PM, Liz Tuddenham wrote:
Don Y <blockedofcourse@foo.invalid> wrote:
Imagine, instead, someone (sous chef?) running out to BUY some potatoes
for the meal and:
- coming home empty handed ("they ran out of potatoes")
I have had a similar scenario when cooking for two of us in my van for
12 days. My companion was in the early stages of dementia and things
kept going 'missing', only to turn up next day in the most unexpected places. That included items of food, so changes to a planned meal had
to be improvised as I went along and I had to always bear in mind what
to do if something we had bought for supper just wasn't there when I
needed it.
I've learned to double-check the ACTUAL availability of ingredients
when baking.
On 14/01/2025 18:10, Don Y wrote:
I am surprised (disturbed?) at the problems people seem to have
sorting these things out in their thought processes. I don't
*believe* people think strictly "serially" but I am beginning to
question that belief as I witness smart/capable people stuck in
that mindset!
Most people do think in a very linear fashion so I'm not too surprised at your
finding. Good realtime programmers are as rare as hen's teeth.
I've been finding problems with their implementations that
would not be present if they TRULY "thought in parallel". Things
that should be obvious seem to slip right past them. This came
to a head when I asked a colleague to explain multitasking:
"Well, FIRST, the processor does... and THEN..."
"Ah, 'THEN'! So, you are thinking about multitasking as the
SERIALIZATION of multiple tasks instead of the CONCURRENT
execution of them! So, when your code is run in true parallel
form (multiple cores, multiple processors), all of those hidden
assumptions that you've baked into your design fall apart because
they are no longer implicitly serialized!
There are major shrink wrap programs out there that have these bugs.
Excel 2007 as first released on a multi core machine and programmed via VBA the
charting package would quite happily try to plot data points *before* the axis
scales had been established. This did not end well and broke a lot of previously stable working commercial code.
It could be "solved" by the addition of suitable small delays here and there to
prevent the race condition triggering. Heavy users went back to XL2003 which I
recall was a particularly good vintage.
Can anyone suggest a simpler "real world" problem to promote these
"situations/scenarios"?
For things to get interesting you need at least 4 threads with some of them depending on synchronisation with the others. Building a house or putting up one of those insert tab A into slot B tents might do it.
A house without foundations will obviously fall down and putting the roof on before plastering and fitting out the interior is essential.
A variant of this cartoon might also get people's attention:
https://www.businessballs.com/amusement-stress-relief/tree-swing-cartoon-pictures-early-versions/
... Especially as so many people seem to use spreadsheets
in lieu of (real) databases. :<
Don Y <blockedofcourse@foo.invalid> wrote:
On 1/14/2025 2:12 PM, Liz Tuddenham wrote:
I have had a similar scenario when cooking for two of us in my van for
12 days. My companion was in the early stages of dementia and things
kept going 'missing', only to turn up next day in the most unexpected
places. That included items of food, so changes to a planned meal had
to be improvised as I went along and I had to always bear in mind what
to do if something we had bought for supper just wasn't there when I
needed it.
I've learned to double-check the ACTUAL availability of ingredients
when baking.
The problem was that the vegetables were there on the worktop when I
started. -they just weren't there when I came to put them in the
saucepan. A thorough search of the van failed to find them.
The next day I discovered that my frend had put them underneath the van instead of the milk, which was normally kept there because it stayed
cooler.
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
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.
In message <vm69a2$2h52d$1@dont-email.me>, Don Y ><blockedofcourse@foo.invalid> writes
I am surprised (disturbed?) at the problems people seem to have
sorting these things out in their thought processes. I don't
*believe* people think strictly "serially" but I am beginning to
question that belief as I witness smart/capable people stuck in
that mindset!
It's simple project engineering and resource management . PERT ,
Critical path analysis, lead times , Gantt charts, even Microsoft
Project if you must. You must be talking to non-engineers.
Brian
I am surprised (disturbed?) at the problems people seem to have
sorting these things out in their thought processes. I don't
*believe* people think strictly "serially" but I am beginning to
question that belief as I witness smart/capable people stuck in
that mindset!
Don Y <blockedofcourse@foo.invalid> wrote:
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.
All of those can be done on a spreadsheet. ...and similar checks can be
done between cells in different rows. The check formula is written into
a 'hidden' cell and the final result is displayed in a 'locked' cell.
If someone puts in faulty data, the spreadsheet can't stop them but it
can ensure that the dud data doesn't appear in the output.
I use spreadsheets for all sorts of things: calculating component
values, customers and accounts, encoding sensitive information,
addressing envelopes, uploading invoices to the Web ...etc.
I tried using a database to keep track of my Christmas Cards, but find
it slow and restrictive compared with a spreadsheet.
In message <vm69a2$2h52d$1@dont-email.me>, Don Y <blockedofcourse@foo.invalid>
writes
I am surprised (disturbed?) at the problems people seem to have
sorting these things out in their thought processes. I don't
*believe* people think strictly "serially" but I am beginning to
question that belief as I witness smart/capable people stuck in
that mindset!
It's simple project engineering and resource management . PERT , Critical path
analysis, lead times , Gantt charts, even Microsoft Project if you must. You must be talking to non-engineers.
Don Y <blockedofcourse@foo.invalid> wrote:
[...]
Ah. "Can you wait outside (in another room) while I make dinner?" :>
Tricky in a 5ft x 8ft van conversion.
< http://www.poppyrecords.co.uk/Van/vanconversion.htm>
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
On 1/16/2025 3:14 AM, Martin Brown wrote:
On 14/01/2025 18:10, Don Y wrote:
I am surprised (disturbed?) at the problems people seem to have
sorting these things out in their thought processes. I don't
*believe* people think strictly "serially" but I am beginning to
question that belief as I witness smart/capable people stuck in
that mindset!
Most people do think in a very linear fashion so I'm not too surprised
at your finding. Good realtime programmers are as rare as hen's teeth.
When you think of a circuit diagram, do you "track" an electron through
the wiring? Don't you conceptualize "this block does this WHILE this
other block is doing that"?
People seem to tolerate the notion of an ISR running WHILE their code
is running. They don't seem to think of it as "my code is running and
THEN an interrupt comes along and does...".
Yet, when they think of multitasking (and beyond), they seem to
intentionally serialize the actors' actions. Why the difference
in mindsets?
It could be "solved" by the addition of suitable small delays here and
there to prevent the race condition triggering. Heavy users went back
to XL2003 which I recall was a particularly good vintage.
Dunno. I've not used a spreadsheet since Quattro. Never really saw the appeal (if I need some set of values calculated, I'll just write a bit of code to do it unambiguously -- instead of wondering what quirks the
spreadsheet imposes). Especially as so many people seem to use
spreadsheets
in lieu of (real) databases. :<
On 16/01/2025 12:03, 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
Real databases implement some form of content addressable storage.
Don Y <blockedofcourse@foo.invalid> wrote:...
On 1/16/2025 5:03 AM, Liz Tuddenham wrote:
Don Y <blockedofcourse@foo.invalid> wrote:
All of those can be done on a spreadsheet. ...and similar checks can be
done between cells in different rows. The check formula is written into
a 'hidden' cell and the final result is displayed in a 'locked' cell.
If someone puts in faulty data, the spreadsheet can't stop them but it
can ensure that the dud data doesn't appear in the output.
I use spreadsheets for all sorts of things: calculating component
values, customers and accounts, encoding sensitive information,
addressing envelopes, uploading invoices to the Web ...etc.
I tried using a database to keep track of my Christmas Cards, but find
it slow and restrictive compared with a spreadsheet.
--
~ Liz Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk
On 16/01/2025 11:41, Don Y wrote:
On 1/16/2025 3:14 AM, Martin Brown wrote:
On 14/01/2025 18:10, Don Y wrote:
I am surprised (disturbed?) at the problems people seem to have
sorting these things out in their thought processes. I don't
*believe* people think strictly "serially" but I am beginning to
question that belief as I witness smart/capable people stuck in
that mindset!
Most people do think in a very linear fashion so I'm not too surprised at >>> your finding. Good realtime programmers are as rare as hen's teeth.
When you think of a circuit diagram, do you "track" an electron through
the wiring? Don't you conceptualize "this block does this WHILE this
other block is doing that"?
People seem to tolerate the notion of an ISR running WHILE their code
is running. They don't seem to think of it as "my code is running and
THEN an interrupt comes along and does...".
An ISR is sufficiently small and so mission critical that if it doesn't save and restore the registers it affects properly the OS dies PDQ.
Yet, when they think of multitasking (and beyond), they seem to
intentionally serialize the actors' actions. Why the difference
in mindsets?
Most people can't imagine the various tasks running at different speeds either
timesliced or by priority. There is always a tendency amongst programmer to think that their task is *the* most important one. The thing you learn quickly
on truly massively parallel hardware is that the manager task that keeps all of
the allocated workers busy is by far the highest priority.
It could be "solved" by the addition of suitable small delays here and there
to prevent the race condition triggering. Heavy users went back to XL2003 >>> which I recall was a particularly good vintage.
Dunno. I've not used a spreadsheet since Quattro. Never really saw the >> appeal (if I need some set of values calculated, I'll just write a bit of
code to do it unambiguously -- instead of wondering what quirks the
I like spreadsheets for making test data. The sort of mistakes you can make in
a spreadsheet implementation are almost entirely orthogonal to those you can make in a conventional programming language. As such it makes a great scratch pad for developing tricky algorithms with all of the internal workings clearly
visible on the screen.
spreadsheet imposes). Especially as so many people seem to use spreadsheets
in lieu of (real) databases. :<
Sigh - yes I know they do :(
Up to a couple of thousand lines it isn't *too* bad but after that it goes downhill very quickly. Doesn't stop people - typically middle managers with very limited skills having silly sized ones though.
Don Y <blockedofcourse@foo.invalid> wrote:
[...]
Ah. "Can you wait outside (in another room) while I make dinner?" :>
Tricky in a 5ft x 8ft van conversion.
< http://www.poppyrecords.co.uk/Van/vanconversion.htm>
On Thu, 16 Jan 2025 15:10:37 +0000, brian <nospam@b-howie.co.uk>
wrote:
In message <vm69a2$2h52d$1@dont-email.me>, Don Y >><blockedofcourse@foo.invalid> writes
I am surprised (disturbed?) at the problems people seem to have
sorting these things out in their thought processes. I don't
*believe* people think strictly "serially" but I am beginning to
question that belief as I witness smart/capable people stuck in
that mindset!
It's simple project engineering and resource management . PERT ,
Critical path analysis, lead times , Gantt charts, even Microsoft
Project if you must. You must be talking to non-engineers.
Brian
The more such management tools that you use, the slower a project will
go.
The key observation is that when things are serialized, they happen >sequentially.
Databases can also be backed up as human readable text files.
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.
In message <rraiojlip0hl9vjaa742fmtq9dpmo2v2l1@4ax.com>, john larkin ><JL@gct.com> writes
On Thu, 16 Jan 2025 15:10:37 +0000, brian <nospam@b-howie.co.uk>
wrote:
In message <vm69a2$2h52d$1@dont-email.me>, Don Y >>><blockedofcourse@foo.invalid> writes
I am surprised (disturbed?) at the problems people seem to have
sorting these things out in their thought processes. I don't
*believe* people think strictly "serially" but I am beginning to >>>>question that belief as I witness smart/capable people stuck in
that mindset!
It's simple project engineering and resource management . PERT ,
Critical path analysis, lead times , Gantt charts, even Microsoft
Project if you must. You must be talking to non-engineers.
Brian
The more such management tools that you use, the slower a project will
go.
The key observation is that when things are serialized, they happen >>sequentially.
PERT and the like handles parallel processing paths , in fact it almost >forces you do it . When things are concurrent they happen in parallel .
B .
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).
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.
"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.
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.
On 1/16/2025 8:16 AM, Liz Tuddenham wrote:
Don Y <blockedofcourse@foo.invalid> wrote:
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.
All of those can be done on a spreadsheet. ...and similar checks can be done between cells in different rows. The check formula is written into
a 'hidden' cell and the final result is displayed in a 'locked' cell.
If someone puts in faulty data, the spreadsheet can't stop them but it
can ensure that the dud data doesn't appear in the output.
It's a kludge. How do you handle the 302K files on THIS machine?
Given that a PATHNAME can be thousands of characters in length?
Tell me where all of the files named "Readme" are located...
How quickly for you to get a result from the tool? Or, how many
have the hash "2094230953408573847503485034038298028023984"?
I use spreadsheets for all sorts of things: calculating component
values, customers and accounts, encoding sensitive information,
addressing envelopes, uploading invoices to the Web ...etc.
I use databases (tables/relations) for all of that. Wanna know the
last time I telephoned XYZ Corporation? Or, who's associated
with a particular phone number? Or, how many billable hours I
charged on project XYZ in the week of January 25, 1990 (to
prepare an invoice)?
"Tables" are particularly attractive in constraining data. E.g.,
if a user types in a city name, I can present a list of *potential*
state names (because I know which city names are valid in each state).
Or, a list of associated ZIP (postal) codes, from which I could
determine the state.
This is particularly valuable with things like speech I/O as it
is much easier to recognize words in a limited/constrained vocabulary
than it is to recognize unconstrained speech. "Call <entity>"
knows that "entity" has to be one of the entities listed in the
address book -- otherwise, it wouldn't make sense. So, if the
speech recognizer THINKS the user said "rolf", it would know that
to be incorrect if there are no "Rolfs" in the address book -- maybe
"Ralph"?
I tried using a database to keep track of my Christmas Cards, but find
it slow and restrictive compared with a spreadsheet.
"Databases" are just tables. So, you're doing something wrong.
You have to have a "front-end" that acts on your behalf to manage
the interface. E.g., I wouldn't try to manually piece together
C: \ Windows \ notepad.exe
or:
C: \ Users \ Don \ Desktop \ apc_1500va.zip \ schem \ page5.png
by examining each tuple. Instead, I let a query do all of that
and give me the result AS IF it had been stored there, directly.
I can do this in real-time as I am scanning a mounted volume
to verify that every file is "intact" (compute hash, compare to
stored hash, store date/time of this verification, advance to next
file) at the speed of the medium. When "done", email a list
of corrupt/missing files to $USER so they can take action to
restore them from duplicates on other media (which the database
can identify based on stored sizes and hashes: "Mount volume
XYZ so I can restore the following entities...")
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?
"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 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
- 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.
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.
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".)
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)
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 415 |
Nodes: | 16 (2 / 14) |
Uptime: | 107:47:26 |
Calls: | 8,692 |
Calls today: | 1 |
Files: | 13,257 |
Messages: | 5,948,376 |