Re: Oracle and PICK
Date: Sun, 18 Apr 2004 13:38:18 GMT
Message-ID: <exvgc.12232$l75.4493_at_newsread2.news.atl.earthlink.net>
However, I would like to know if the Oracle nested table I series, as does Pick, stores the data 'flat' as does tape, with hex characters determining the multiple value 'count' as in
ORDER_SEQ <1,1> ORDER_SEQ <1,2> ORDER_SEQ <1,3> etc ORDER_PROD <1,1>
ORDER_PROD <1,2>
ORDER_PROD <1,3> etc
This would lead to efficiency in reading an ORDER from disk but would impact on the SQL necessary to do anything with it. Oracle's SQL, as does all SQL, suffers from the inefficiency of parsing the SQL and creating the temporary files necessary when trying to do complex Updates/Queries. Roger Sippl ran into the same problems in 1984 when he developed the specifications for the INNER and OUTER JOINS during a project I was involved with as a VAR, I developed and installed the first 'application' done with his new INFORMIX PERFORM/ACEGO GL. I suggest that the learning necessary to actually 'use' the new nested relationships' SQL, which will be in all mainstream RDBMS products in order to define the multi dimensional world, will be extensive. PICK uses a 3GL programming language in order to overcome such a limitation on implementation.
TCO would still apply ONLY to a Client's perception of the Annual Cost to license and maintain an application, IMHO
Nick
"Laconic2" <laconic2_at_comcast.net> wrote in message
news:0c-dnQAzgNmL7B_dRVn-jg_at_comcast.com...
> Yes, let's go there.
>
> A set of flat surfaces is not a 3 dimensional space.
>
> Disk data is stored 2 dimensionally.
>
> When 3-d storage is built, it will be as different from disks as disks
were
> from tape.
>
>
Received on Sun Apr 18 2004 - 15:38:18 CEST