Re: Pick to Oracle conversion

In article <39m572$e1c_at_ixnews1.ix.netcom.com>

           chuckh_at_ix.netcom.com "Chuck Hamilton" writes:

> In <784210015snz_at_sambusys.demon.co.uk> psb_at_sambusys.demon.co.uk (Paul
> Beardsell) writes:
>
> >In article <39h171$rf2_at_ixnews1.ix.netcom.com>
> > chuckh_at_ix.netcom.com "Chuck Hamilton" writes:
> >
> >> I'm interested in hearing any stories of users that have converted
> >> corporate databases from Pick (or any of the Pick-like DBMSs) to
 Oracle.
> >> How did the performance of Oracle compare to Pick in speed, disk
> >> requirements, system administration, application development
 time,etc.
> >>
> >> TIA.
 
> >Hello Chuck!
> >
> >I don't know anybody who has done so without a complete redesign of
> >the application because typically the Pick application is a decade
> >old and any business changes in that time.
> >
> >Certainly you have to know a lot more things to be able to run Oracle.
> >But I find that a _good_ Pick techie makes a good Oracle techie.
> >Eventually. But Pick techies can be intransigent. They convinced
> >themselves of Pick's superiority when Pick was the best so they don't
> >_want_ to move to Oracle.
>
> The data model is undeniably superior.

Undeniable by whom? I've programmed extensively in both the Pick and Oracle environments and I'm not sure you're right. The issue is certainly not clear cut. For instance, not being able to use chars 251 to 255 is not a desirable feature. Pick multi-values are beaten by Oracle clusters in certain very important features. Traditional Pick direct access to the data via primary key only is restrictive.

> But the client / server tools are
> non-existent and there's no true transactional integrity. Limitations
> which I'm just not willing to live with any more. The application I'm
> designing currently is a datawarehouse. But I'm hoping if I get good
> enough performance that I can convince the company to begin a redesign.
> (This was in our long-term plans anyway.)
>
> >Essential to good performance is good design of the database. The
> >on the fly changes to database structure you have been familiar
> >with in the Pick world are a little more difficult with Oracle.
> >Although adding an extra column to a table is never a problem this
> >cannot be done except DELIBERATELY. And with Oracle you can choose
> >to index columns or to remove an index without changing the
> >application code or halting the application.
> >
> >Disk requirements are higher. Without the building of indexes I
> >would guess that you will need 25% more disk space if your Pick
> >files are correctly sized. Indexes add to that. And you will
> >need indexes.
>
> Whether I go to Oracle or stay with Universe, I was planning on a lot of
> indexing anyway. One of the criteria for this project is fast data
> retrieval (i.e., no queries that tie up the PC for hours on end).
>
> >System admin? Are you moving from a native Pick machine or from
> >UniVerse/Unidata? Because Unix system admin is _different_ and
> >more complicated. And someone will have to adopt a database admin
> >role.
>
> From Universe on an HP9000. The data warehouse will also be on an
> HP9000. A separate one from the "live" system though.
>
> >But for all the added complication the benefits are many. The
> >clincher for me is data and database integrity. Proper transaction
> >boundaries means that any _data_ integrity problems are only caused
> >by bugs in application code. I have been lucky enough never to see
> >a loss of Oracle _database_ integrity. Both I suffered from under
> >Pick (native and UniVerse).
>
> Do you run into any problems having to do with the lack of a READU
> equvilent?

Don't be deceived by the current thread in comp.databases.pick in which it is said that there is no READU equivalent in a RDMBS. The FOR UPDATE clause of SELECT places a mandatory lock on the row(s) selected. Often, though, explicit locking is not required. See my posting today to this effect in comp.databases.pick.

> >Speed of development. With Oracle you can code up your own front
> >end in C using the Pro*C precompiler or the OCI library calls.
> >But, unlike Pick, writing your own front-end screen programs is
> >very unusual in Oracle. A number of vendors provide tools for
> >building user input & enquiry screens and reports. I have only
> >used Oracle's and would say that Oracle SQL*Forms development
 But the client / server tools are >is much quicker than coding in Pick Basic and nearly as quick
> >as System Builder. Forms results in much flashier and easier to
> >use apps than either, typically. SQL*Reportwriter is a much better
> >report writer than any I have seen in the Pick world. It is quick
> >to develop in too.
>
> Thanks for the input. I'll be saving a copy of this article.
>
> Any suggestions on what research would be beneficial for both the
> initial data warehouse application, and the eventual migration to Oracle
> (or some other SQL RDBMS)?

No. What _is_ a data warehouse?

But you're doing the right thing in intending to do some reading. You must get the database normalisation right for your application.

-- 
Paul Beardsell                          SAM Business Systems Ltd
~~~~~~~~~~~~~~                          21 Finn House, Bevenden St,
pbeardsell_at_cix.compulink.co.uk          London, N1-6BN, UK.
psb_at_sambusys.demon.co.uk                (+44 or 0)71 608-2391