Re: In an RDBMS, what does "Data" mean?
Date: Fri, 11 Jun 2004 08:14:19 +0200
Message-ID: <40c94dbc$0$49150$e4fe514c_at_news.xs4all.nl>
Bill H wrote:
> Notes embedded.
>>"mAsterdam" <mAsterdam_at_vrijdag.org> wrote... >>>Anthony W. Youngman wrote... >>> >>>So if I put my data into an MV database I can access it as if it were in >>>an RDBMS. However, the converse is not true. >> >>It would be very interesting to know - in some detail - >>what kind of data gives difficulties in putting stuff >>from a RDBMS into a MV database. >>This maybe somewhat awkward in this newsgroup, because some >>will be just waiting to say: See? You *can* express proposition_set(x) >>in a RDBMS, and you *can't* in MV, therefore MV is better.
Heh. Strange typo - sorry.
>>More is not a priori better. >> >>But I trust you can stand that reaction. Could you give some examples?
>
>
> Here's an A/P invoice record. The view is vertical, not horizontal. The
> numbers on the left indicate the field location# in the physical string on
> disk. The unnumbered value is the record key.
>
> 340*VR3-2
> 001 480
> 002 13279
> 003 13210
> 004 74*578
> 005 LOAN PAYMENT, 3/2004
> 006 -297645
> 007 0
> 008 -297645
> 009 5170]3370]5170]3370
> 010 -101261]-196384]0]0
> 011 200404
> 012 200404
> 013
> 014
> 015 AUTO
> 016
> 017 74
>
> The disk storage would look like:
>
> ^^340*VR3-2^480^13279^12114^74*578^LOAN PAYMENT,
> 3/2004^-297645^0^-297645^5170]3370]5170]3370^-101261]-196384]0]0^200404^2004
> 04^^^AUTO^^74
I can see the mapping between the 'storage' and the 'vertical view' representation. The FILE definition (if this is the correct term) would help to get the example clear, no?
> The contents of field#s 009 & 010 are the G/L acct#s assigned this invoice
> and the "associated" G/L amounts allocated to each G/L acct#. The last two
> "values" of field# 10 are zero (0), but could just as easily be nothing so
> the field could look like:
>
> 010 -101261]-196384]]
>
> There are no data types in this record. Field#s 002 & 003 are dates where
> each date is the number of days past 31 Dec 1967 (kind of like unix's # of
> seconds past midnight on 01 January 1970.
So, a different time-offset than unix.
Different internal date representation.
No big deal, IMO.
> The values of field#s 006, 008,
> and 010 are monetary values with the decimal stripped, so the value 25 would
> indicate $.25 (or .25 of whatever denomination used).
>
> To load a valid date into a Pick-like dbms (mvDbms) a conversion needs to be
> done similar to what is done for Unix. The same is true for money amounts.
> However, extraction is very easy so that:
>
> ::LIST APOPEN '340*VR3-2' INVDATE DUEDATE ACCTS AMTS
> Page 1 APOPEN
>
> APOPEN.... INV-DATE DUE-DATE ACCT. ACCT/AMTS....
>
> 340*VR3-2 03-01-01 05-09-04 5170 1,012.61-
> 3370 1,963.84-
> 5170 0.00
> 3370 0.00
>
> [405] 1 items listed out of 1 items.
>
> or the relational way:
>
> ::LIST APOPEN '340*VR3-2' BY-EXP ACCTS INVDATE DUEDATE ACCTS AMTS
> Page 1 APOPEN
>
> APOPEN.... INV-DATE DUE-DATE ACCT. ACCT/AMTS....
>
> 340*VR3-2 03-01-01 05-09-04 3370 1,963.84-
> 340*VR3-2 03-01-01 05-09-04 3370 0.00
> 340*VR3-2 03-01-01 05-09-04 5170 1,012.61-
> 340*VR3-2 03-01-01 05-09-04 5170 0.00
>
> [405] 4 items listed out of 1 items.
Hm... no big deal either, or is it? Grouping / levelled duplicate suppression and it's the same, no?
> (if this appears in a proportional font simply cut & paste to notepad)
>
> I hope this answered your question. :-)
Certainly on the detail level. But what is the problem?
I don't see the RDBMS ==> MV problem - but I may
be overlooking something.
Anyway, thank you for your effort.
Received on Fri Jun 11 2004 - 08:14:19 CEST