Sujet : Re: The joy of SQL
De : 186283 (at) *nospam* ud0s4.net (186282@ud0s4.net)
Groupes : comp.os.linux.miscDate : 07. Nov 2024, 01:07:41
Autres entêtes
Organisation : wokiesux
Message-ID : <x2udnQJd-vlTmbH6nZ2dnZfqn_adnZ2d@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/6/24 2:03 PM, Lawrence D'Oliveiro wrote:
On Tue, 5 Nov 2024 01:54:56 -0500, 186282@ud0s4.net wrote:
On 11/4/24 5:09 PM, Lawrence D'Oliveiro wrote:
>
On Sun, 3 Nov 2024 20:36:29 -0500, 186282@ud0s4.net wrote:
>
Why join when the MV approach keeps yer data in an already-joined
state ???
>
Because the MV approach makes that hard to maintain.
>
>
Never noticed that ...
What kind of database doesn’t need updating?
That wasn't my point ... just saying that updates
ain't as difficult as you seem to think.
You CAN download OpenQM if you want, see how the MV approach can be
useful.
LDAP has multi-valued attributes. But then, it has a different model where
all the records are in the same table, and the primary key has a
hierarchical form. And it has a “modify” operation that can add/remove
individual values for an attribute.
LDAP is a kinda lightweight 'DB' - not built to
be really 'general purpose'.
PICK ... kinda depends on your POV as to whether
all records are in one table or not. Easier to
just think of each record as a long string, with
delims marking fields/subfields/etc. MV records
are usually not all THAT long so straight searching
goes quick but you COULD add a small hash table
if there were mass quantities of fields/subfields.
Anyway, get or borrow a MV DB and fool around
with it yourself.