Re: In an RDBMS, what does "Data" mean?

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Fri, 11 Jun 2004 08:14:19 +0200
Message-ID: <40c94dbc$0$49150$e4fe514c@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 - 01:14:19 CDT