Re: Serial, concurrent, parallel

Liste des GroupesRevenir à se design 
Sujet : Re: Serial, concurrent, parallel
De : liz (at) *nospam* poppyrecords.invalid.invalid (Liz Tuddenham)
Groupes : sci.electronics.design
Date : 17. Jan 2025, 10:36:02
Autres entêtes
Organisation : Poppy Records
Message-ID : <1r6asl6.1j59su61nmck1sN%liz@poppyrecords.invalid.invalid>
References : 1 2 3 4 5 6 7
User-Agent : MacSOUP/2.4.6
Don Y <blockedofcourse@foo.invalid> wrote:

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...")

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.


--
~ Liz Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

Date Sujet#  Auteur
14 Jan 25 * Serial, concurrent, parallel35Don Y
14 Jan 25 +* Re: Serial, concurrent, parallel9Liz Tuddenham
14 Jan 25 i`* Re: Serial, concurrent, parallel8Don Y
14 Jan 25 i `* Re: Serial, concurrent, parallel7Liz Tuddenham
15 Jan 25 i  `* Re: Serial, concurrent, parallel6Don Y
16 Jan 25 i   `* Re: Serial, concurrent, parallel5Liz Tuddenham
16 Jan 25 i    `* Re: Serial, concurrent, parallel4Don Y
16 Jan 25 i     `* Re: Serial, concurrent, parallel3Liz Tuddenham
16 Jan 25 i      +- Re: Serial, concurrent, parallel1Don Y
16 Jan 25 i      `- Re: Serial, concurrent, parallel1ehsjr
16 Jan 25 +* Re: Serial, concurrent, parallel20Martin Brown
16 Jan 25 i`* Re: Serial, concurrent, parallel19Don Y
16 Jan 25 i +* Re: Serial, concurrent, parallel16Liz Tuddenham
16 Jan 25 i i+* Re: Serial, concurrent, parallel13Don Y
16 Jan 25 i ii`* Re: Serial, concurrent, parallel12Liz Tuddenham
16 Jan 25 i ii +* Re: Serial, concurrent, parallel5Don Y
17 Jan 25 i ii i`* Re: Serial, concurrent, parallel4Liz Tuddenham
17 Jan 25 i ii i `* Re: Serial, concurrent, parallel3Don Y
17 Jan 25 i ii i  +- Re: Serial, concurrent, parallel1Don Y
17 Jan 25 i ii i  `- Re: Serial, concurrent, parallel1Don Y
16 Jan 25 i ii `* Re: Serial, concurrent, parallel6Edward Rawde
17 Jan 25 i ii  `* Re: Serial, concurrent, parallel5Don Y
17 Jan 25 i ii   `* Re: Serial, concurrent, parallel4Edward Rawde
17 Jan 25 i ii    `* Re: Serial, concurrent, parallel3Don Y
17 Jan 25 i ii     `* Re: Serial, concurrent, parallel2Edward Rawde
17 Jan 25 i ii      `- Re: Serial, concurrent, parallel1Don Y
16 Jan 25 i i`* Re: Serial, concurrent, parallel2Martin Brown
16 Jan 25 i i `- Re: Serial, concurrent, parallel1Don Y
16 Jan 25 i `* Re: Serial, concurrent, parallel2Martin Brown
16 Jan 25 i  `- Re: Serial, concurrent, parallel1Don Y
16 Jan 25 `* Re: Serial, concurrent, parallel5brian
16 Jan 25  +* Re: Serial, concurrent, parallel3john larkin
17 Jan 25  i`* Re: Serial, concurrent, parallel2brian
17 Jan 25  i `- Re: Serial, concurrent, parallel1john larkin
16 Jan 25  `- Re: Serial, concurrent, parallel1Don Y

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal