| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 42 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:20:33 |
| Calls: | 220 |
| Calls today: | 1 |
| Files: | 824 |
| Messages: | 121,522 |
| Posted today: | 6 |
I don't think there's any distinct "advantage" these
days in either flat-file or MV. Plusses and minuses
for each approach. It's all a matter of how you FEEL
data should be structured/stored.
In short, 'religion'.
IMHO, MV is still the 'best', 'most logical', 'most compact'.
On Sat, 2 Nov 2024 03:21:40 -0400, 186282@ud0s4.net wrote:
IMHO, MV is still the 'best', 'most logical', 'most compact'.
Except when you need to do updates.
On 02/11/2024 05:19, 186282@ud0s4.net wrote:
I don't think there's any distinct "advantage" these
days in either flat-file or MV. Plusses and minuses
for each approach. It's all a matter of how you FEEL
data should be structured/stored.
In short, 'religion'.
MV? no one seems to know what 'MV' is. Did you invent it?
Insofar as data storage goes there are considerable advantages to a normalised database with indices et al.
It is not a religious choice.
The religion comes in with supporters who have been told that
*irrespective of the actual context or uses* it is 'simply the best'
Rules are for the guidance of wise men and the obedience of fools.
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.
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.
On 11/2/24 8:15 PM, Lawrence D'Oliveiro wrote:
On Sat, 2 Nov 2024 03:21:40 -0400, 186282@ud0s4.net wrote:
IMHO, MV is still the 'best', 'most logical', 'most compact'.
Except when you need to do updates.
As said, that's NOT as complex or resource-consuming as you believe.
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.
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.
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.
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 ???
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).
On Sun, 3 Nov 2024 20:36:29 -0500, 186282@ud0s4.net wrote:
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.
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 ???
Because the MV approach makes that hard to maintain.
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.
Python is quite good at SQL database manipulations. This include
setting up complicated joins.
I have some basic tutorials here <https://gitlab.com/ldo/python_topics_notebooks/-/blob/master/Databases,%20Iterators%20&%20Looping.ipynb?ref_type=heads>
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).
I know, it was crap. Probably scarred you for life, which is why you
think the way you do.
SQL and flat-file DBs are kind of the all-gobbling monsters.
But MV is still the better, saner, way to organize many kinds of
data.
On Wed, 30 Oct 2024 01:55:35 -0400, 186282@ud0s4.net wrote:
SQL and flat-file DBs are kind of the all-gobbling monsters.
But MV is still the better, saner, way to organize many kinds of
data.
The trouble with unnormalized fields is: how do you do updates? You have
to delete all the values and insert them all again.
On 10/30/24 10:21 PM, Lawrence D'Oliveiro wrote:
On Wed, 30 Oct 2024 01:55:35 -0400, 186282@ud0s4.net wrote:
SQL and flat-file DBs are kind of the all-gobbling monsters.
But MV is still the better, saner, way to organize many kinds of
data.
The trouble with unnormalized fields is: how do you do updates? You have
to delete all the values and insert them all again.
Updates CAN be annoying.
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 ...
You CAN download OpenQM if you want, see how the MV approach can be
useful.
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?
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.
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 ...
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'.
On 10/31/24 2:20 AM, Lawrence D'Oliveiro wrote:
On Thu, 31 Oct 2024 01:35:23 -0400, 186282@ud0s4.net wrote:
On 10/30/24 10:21 PM, Lawrence D'Oliveiro wrote:
On Wed, 30 Oct 2024 01:55:35 -0400, 186282@ud0s4.net wrote:
SQL and flat-file DBs are kind of the all-gobbling monsters.
But MV is still the better, saner, way to organize many kinds of
data.
The trouble with unnormalized fields is: how do you do updates? You
have to delete all the values and insert them all again.
Updates CAN be annoying.
Easy way to remove the annoyance: normalize your field values.
But the 'easy' way removes some of your flexibility and reasoning
ability in the process.
On Thu, 31 Oct 2024 01:35:23 -0400, 186282@ud0s4.net wrote:
On 10/30/24 10:21 PM, Lawrence D'Oliveiro wrote:
On Wed, 30 Oct 2024 01:55:35 -0400, 186282@ud0s4.net wrote:
SQL and flat-file DBs are kind of the all-gobbling monsters.
But MV is still the better, saner, way to organize many kinds of
data.
The trouble with unnormalized fields is: how do you do updates? You have >>> to delete all the values and insert them all again.
Updates CAN be annoying.
Easy way to remove the annoyance: normalize your field values.
On Thu, 31 Oct 2024 23:57:11 -0400, 186282@ud0s4.net wrote:
On 10/31/24 2:20 AM, Lawrence D'Oliveiro wrote:
On Thu, 31 Oct 2024 01:35:23 -0400, 186282@ud0s4.net wrote:
On 10/30/24 10:21 PM, Lawrence D'Oliveiro wrote:
On Wed, 30 Oct 2024 01:55:35 -0400, 186282@ud0s4.net wrote:
SQL and flat-file DBs are kind of the all-gobbling monsters.
But MV is still the better, saner, way to organize many kinds of
data.
The trouble with unnormalized fields is: how do you do updates? You
have to delete all the values and insert them all again.
Updates CAN be annoying.
Easy way to remove the annoyance: normalize your field values.
But the 'easy' way removes some of your flexibility and reasoning
ability in the process.
No it doesn’t. Prove me wrong.
On 11/1/24 12:14 AM, Lawrence D'Oliveiro wrote:
On Thu, 31 Oct 2024 23:57:11 -0400, 186282@ud0s4.net wrote:
On 10/31/24 2:20 AM, Lawrence D'Oliveiro wrote:
On Thu, 31 Oct 2024 01:35:23 -0400, 186282@ud0s4.net wrote:
On 10/30/24 10:21 PM, Lawrence D'Oliveiro wrote:
The trouble with unnormalized fields is: how do you do updates? You >>>>>> have to delete all the values and insert them all again.
Updates CAN be annoying.
Easy way to remove the annoyance: normalize your field values.
But the 'easy' way removes some of your flexibility and reasoning
ability in the process.
No it doesn’t. Prove me wrong.
This can't be "proven" per-se ... it's a matter of how you "feel"
about how data should be represented to best effect/clarity. Call it 'religion' if you want ...
On Fri, 1 Nov 2024 02:45:56 -0400, 186282@ud0s4.net wrote:
On 11/1/24 12:14 AM, Lawrence D'Oliveiro wrote:
On Thu, 31 Oct 2024 23:57:11 -0400, 186282@ud0s4.net wrote:
On 10/31/24 2:20 AM, Lawrence D'Oliveiro wrote:
On Thu, 31 Oct 2024 01:35:23 -0400, 186282@ud0s4.net wrote:
On 10/30/24 10:21 PM, Lawrence D'Oliveiro wrote:
The trouble with unnormalized fields is: how do you do updates? You >>>>>>> have to delete all the values and insert them all again.
Updates CAN be annoying.
Easy way to remove the annoyance: normalize your field values.
But the 'easy' way removes some of your flexibility and reasoning
ability in the process.
No it doesn’t. Prove me wrong.
This can't be "proven" per-se ... it's a matter of how you "feel"
about how data should be represented to best effect/clarity. Call it
'religion' if you want ...
“Religion” is when followers are rewarded for believing in doctrine, not just in the absence of evidence, but directly contrary to the evidence.
In other words, I think you’ve just admitted my point.
On 11/1/24 4:56 PM, Lawrence D'Oliveiro wrote:
On Fri, 1 Nov 2024 02:45:56 -0400, 186282@ud0s4.net wrote:
On 11/1/24 12:14 AM, Lawrence D'Oliveiro wrote:
On Thu, 31 Oct 2024 23:57:11 -0400, 186282@ud0s4.net wrote:
On 10/31/24 2:20 AM, Lawrence D'Oliveiro wrote:
On Thu, 31 Oct 2024 01:35:23 -0400, 186282@ud0s4.net wrote:
On 10/30/24 10:21 PM, Lawrence D'Oliveiro wrote:
The trouble with unnormalized fields is: how do you do updates? >>>>>>>> You have to delete all the values and insert them all again.
Updates CAN be annoying.
Easy way to remove the annoyance: normalize your field values.
But the 'easy' way removes some of your flexibility and reasoning
ability in the process.
No it doesn’t. Prove me wrong.
This can't be "proven" per-se ... it's a matter of how you "feel"
about how data should be represented to best effect/clarity. Call it
'religion' if you want ...
“Religion” is when followers are rewarded for believing in doctrine,
not just in the absence of evidence, but directly contrary to the
evidence.
In other words, I think you’ve just admitted my point.
And you just admitted mine :-)
On Sat, 2 Nov 2024 01:19:13 -0400, 186282@ud0s4.net wrote:
On 11/1/24 4:56 PM, Lawrence D'Oliveiro wrote:
On Fri, 1 Nov 2024 02:45:56 -0400, 186282@ud0s4.net wrote:
On 11/1/24 12:14 AM, Lawrence D'Oliveiro wrote:
On Thu, 31 Oct 2024 23:57:11 -0400, 186282@ud0s4.net wrote:
On 10/31/24 2:20 AM, Lawrence D'Oliveiro wrote:
On Thu, 31 Oct 2024 01:35:23 -0400, 186282@ud0s4.net wrote:
On 10/30/24 10:21 PM, Lawrence D'Oliveiro wrote:
The trouble with unnormalized fields is: how do you do updates? >>>>>>>>> You have to delete all the values and insert them all again.
Updates CAN be annoying.
Easy way to remove the annoyance: normalize your field values.
But the 'easy' way removes some of your flexibility and reasoning
ability in the process.
No it doesn’t. Prove me wrong.
This can't be "proven" per-se ... it's a matter of how you "feel"
about how data should be represented to best effect/clarity. Call it
'religion' if you want ...
“Religion” is when followers are rewarded for believing in doctrine, >>> not just in the absence of evidence, but directly contrary to the
evidence.
In other words, I think you’ve just admitted my point.
And you just admitted mine :-)
The fact of normalized attributes being easier to update isn’t a religious issue: it’s a well-established foundation element of database theory.
It’s
the reason why we have first normal form. And subsequent higher normal
forms impose further restrictions which in their turn make other kinds of updates easier.