Re: The joy of SQL

Liste des GroupesRevenir à ol misc 
Sujet : Re: The joy of SQL
De : 186283 (at) *nospam* ud0s4.net (186282@ud0s4.net)
Groupes : comp.os.linux.misc
Date : 04. Nov 2024, 02:36:29
Autres entêtes
Organisation : wokiesux
Message-ID : <SIWdnVp4xI2DuLX6nZ2dnZfqnPudnZ2d@earthlink.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
On 11/3/24 6:30 PM, Lawrence D'Oliveiro wrote:
On Sat, 2 Nov 2024 21:48:47 -0400, 186282@ud0s4.net wrote:
 
MV = Multi-Valued = Data fields that can hold long lists of that KIND
of information. If you have a fleet-tracking DB then there'd be ONE
field saying "mileage" and likely another for "fuel-added" and they'd
just be added-to over time.
 That’s just a single total in each field.
   It's every like-value in one field - a 'list' so
   to speak - divided as sub-values - but sub-sub-
   values are also legit.

The record for that vehicle is read all-at-once, rather than there
being dozens, hundreds, of records for said vehicle every time it
was fueled-up.
 This is why you have joins: so that you can retrieve multiple related
records with a single query. This is the proper relational way of doing
it.
   Why join when the MV approach keeps yer data
   in an already-joined state ???
   You just read straight across. The RECORD is
   "Vehicle_Number". Inside we have lists (fields)
   for date, mileage, fuel, comment. Date[1] goes
   with Mileage[1] goes with Fuel[1] goes with
   Comment[1]. If you want fuel mileage you add
   a calc field.
   Python, and to some extent FORTRAN, have very good
   string list-manipulation/reading/writing/insertion/deletion
   capabilities ... it'd be fairly easy to set up a MV DB in
   those languages.
   The old PICK-ish DB I spent a decade with used pure
   ASCII-delimited fields (this was pre-unicode, you
   could bring 'em up in a text editor and see all the
   old IBM-BIOS high-ascii symbols).
   255 separated records, 254 separated fields, 253 separated
   sub-fields, 252 sub-sub-fields and so forth - thus you
   could have nearly 200 sub-sub-sub-sub-(etc)-values to
   the data if you were that insane. Going deep programmatically
   for custom sorts and such could be useful however.
   I think PICK wound up being written *in* PICK for the most
   part... a compiler for a sort of BASIC was included so
   PICK would up being writ in PICK-BASIC. The version I
   used DID have some key functions writ in 'C'/ASM though
   for top speed.

Date Sujet#  Auteur
4 Nov 24 * Re: The joy of SQL7Lawrence D'Oliveiro
4 Nov 24 `* Re: The joy of SQL6186282@ud0s4.net
4 Nov 24  `* Re: The joy of SQL5Lawrence D'Oliveiro
5 Nov 24   `* Re: The joy of SQL4186282@ud0s4.net
6 Nov 24    `* Re: The joy of SQL3Lawrence D'Oliveiro
7 Nov 24     `* Re: The joy of SQL2186282@ud0s4.net
7 Nov 24      `- Re: The joy of SQL1Lawrence D'Oliveiro

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal