Re: Oracle system table
Date: Thu, 29 Jul 2010 09:46:24 -0700 (PDT)
Message-ID: <e65cbef5-b56b-45d3-a61f-1c86bf8f2047_at_o7g2000prg.googlegroups.com>
On Jul 28, 7:32 pm, Mladen Gogala <gogala.mla..._at_gmail.com> wrote:
> On Wed, 28 Jul 2010 10:18:03 -0700, joel garry wrote:
> > What exactly is your need? I work on a database that has many tables
> > with no primary keys, so the app makes assumptions...
>
> Having tables with no primary keys is usually a sign of poor design, and
> therefore the application itself is extremely suspicious. When table is
> created, there must be some kind of criteria for identifying the records
> and selecting them from the table. That is what the primary keys are for.
> There has been, as you're probably well aware, a long debate about
> "natural" vs. "generated" (or "unnatural") primary key. Each approach has
> its advantages but there must be a primary key for every table.
>
> --http://mgogala.byethost5.com
This may be an exception to the poor design suspicion, though I agree with you that it normally would be. In this case, it is for historical reasons - the app and programming language came out of the early relational DEC world (Before RDB). In the early '80s, it was common for software providers to write their own file routines. One particular company wrote this relational software accessing its own files, with a patent for getting any row in two disk accesses IIRC. I first saw it at one of their customers in 1981. Later, they upgraded the development tool to handle RMS files, then RDB files. Meanwhile, they were bought by a series of companies, and eventually were absorbed into a melange of app companies. In the early '90's, they rewrote the tool to be able to handle multiple dbms engines, and rewrote the apps. At this time, they were well aware of relational design, as well as what customers needed, so in that sense it was well designed. So think about how sophisticated primary keys were in the Oracle 7.0 days, and its contemporaneous competitors. Anyways, the dbblind tool had had an interesting, though arbitrary solution to primary keys - whichever index was first alphabetically would be the primary key. Of course, 20 years on this sounds stupid, but at the time an app development tool could be far more relational than the engines - and they did have RDB as their primary environment, using the environment to catch other engines up to proper relational theory, as well as allowing 3GL/4GL in the language - like all the stuff people do in PL/SQL now (sometimes wrongly). In Oracle's case, everything would be done by extracting rowid's and data. So you could have automatic projections of how long reports will take to run, report generators, and all that RAD stuff. It even worked with RMS files up to a few years ago.
In the end, people like me wind up hearing about Agile and putting everything in the app layer, and just roll our eyes.
But the apps themselves (now we're talking Enterprise level) have been wrung out and improved, and are easily customizable for business processes, and work really well for certain vertical markets (process manufacturing in particular). Unfortunately, most Oracle customers have either "stabilized" or moved to other players, most newer customers just go MS and jam it all in. And the Chinese own it now - a big part of their Oracle expansion in the '90s was because of NLS and the eastern Pacific market.
jg
-- _at_home.com is bogus. "28. You walk into a grocery store, and see your banks ATM machine being worked on. You see there is actually an ordinary PC with an ordinary keyboard. On the screen is a SQL prompt, and there is no one around. " - Me, 2003 http://www.informationweek.com/news/security/reviews/showArticle.jhtml?articleID=226300230&subSection=NewsReceived on Thu Jul 29 2010 - 11:46:24 CDT