Re: Old Debate, New Day - MVDB vs. Other DBs


Tony Gravagno wrote:
I'm not really reading this thread but I wanted to comment on
something briefly here.

"dawn" wrote:

I'll toss in a little correction here.

Danny wrote:
My bone of contention with the MVDB
world is that working with multi-values and, more importantly,
sub-values, is a major PITA! Do I get an amen?

Dawn replied:
Uh, no. The future direction from all indications is toward
list-valued attributes, or at the very least, set-valued attributes
(lacking order).

Dawn, I think what he's saying is that the MV DBMS is hailed proudly
for its support of values and subvalues but none of the MV
implementations seem to regard values or subvalues as first class data
elements.

I'm on board with the subvalues and in general do not think it is a
good idea to employ subvalues. I had not experienced his issue with
multivalues. It sounds like UniData handles the situation properly
(and perhaps OpenQM does too?) but that other flavors have bugs in that
regard. This is a reason to fix a product, not a reason to avoid MVs,
which if I recall correctly was one possible conclusion drawn.

We define values in Dict definitions using awkward syntax,

agreed

controlling and dependent relationships are defined just as awkwardly,
and using BY-EXP doesn't always work the way one would hope or expect
without playing some games. Subvalues, if they can be defined at all,
aren't even recognized in the AQL process of most MV platforms.

I would wholeheartedly agree that use of subvalues is not in the "best
practices" category. I would not say the same about MV's and still
disagree with that point. It sounds like there are individual products
with bugs, not wholesale issues with MV support. What am I missing?

I'd
say, maybe in agreement with the OP, that this could be an
embarrassing sore spot, that the MV DBMS doesn't truly support MV.

I'm also onboard suggesting that there could be better tools working
with the data model. But even with existing tools, one of the big
advantages of Pick is it's handling of MV's.

(Yes I'm taking a broad brush to the matter as some SQL-biased person
might). Using BASIC, we do have full control over the entire
environment. Unfortunately, since that original effort by Ken Simms,
MV BASIC really hasn't progressed much at all - outside of uniqueness
in ARev/OI BASIC+ and now with QM.

Agreed. And when it does "progress" it can be more frustrating since
it then isn't even standard within the MV space. The lack of industry
standards has been both a blessing and a curse for Pick.

Undoubtedly people are going to respond "but PlatformX does support
_blank_ ...the BASIC in PlatformX has evolved... ProductX makes using
values and subvalues as easy as attributes...". There are many
anecdotes to show that values or subvalues are supported to varying
extents in product-specific ways, but I'll still maintain that the MV
DBMS model in general still only supports a few dimensions - and
questionably.

The OP was talking about multi-values. Are you in agreement that
perhaps one should implement a system in Pick without employing
multi-values? That seems like another of those worst of both worlds
scenarios. Among the advantages to the Pick data model are:

1) Multi-value support
2) 2-valued logic
3) Descriptive rather than prescriptive metadata (with corresponding
pros and cons)
4) Derived data

Sorry, but I'm still not getting the point. I understand the minor
point about a problem with Universe's query language, but that is not
something that has ever been a problem for me with UniData and it
sounds like others have figured out work-arounds enough that they don't
even request a fix from the vendor.

The fact that this bug lept from the Pick side of the house to Universe
is another tip about actual code going from one to the other. I know
that Universe acquired some Pick code with the IN2 acquisition, but I
doubt that is where this came from. Just thinking out loud.

Cheers! --dawn

.

Relevant Pages

  • Re: Data modeling in MV, revisited
    ... including single and multi-values as well as associated multi-values ... I agree that subvalues ought not to be used. ... dependencies, such as is done in relational normalization, but getting ... and beefing up those dictionaries with a lot of virtual ...
    (comp.databases.pick)
  • Re: Old Debate, New Day - MVDB vs. Other DBs
    ... computers. ... levels into the cards usually with one pass for each level with the lower ... for its support of values and subvalues but none of the MV ... that the MV DBMS doesn't truly support MV. ...
    (comp.databases.pick)
  • Re: Old Debate, New Day - MVDB vs. Other DBs
    ... Wasn't if FUN when you dropped the deck? ... for its support of values and subvalues but none of the MV ... A short note from Ladybridge regarding OpenQM, QMQuery and SVMs: ... that the MV DBMS doesn't truly support MV. ...
    (comp.databases.pick)
  • Re: Old Debate, New Day - MVDB vs. Other DBs
    ... I think what he's saying is that the MV DBMS is hailed proudly ... for its support of values and subvalues but none of the MV ... A short note from Ladybridge regarding OpenQM, QMQuery and SVMs: ... that the MV DBMS doesn't truly support MV. ...
    (comp.databases.pick)