Re: Is Oracle deliberately difficult?

On Wed, 30 Aug 2000 11:46:57 -0500, "Jason Kratz" <jkratz_at_rctanalytics.debug.com> wrote:

I really shouldn't, but anyways here goes a bit...

>
>Not good. elitism of any type is not an attribute one should be proud of.
>

Yes it is. When one has been around for 25 years in this industry, the last 19 of which dealing exclusively with databases, relational or not, one gets to be a bit "elitist" when the "latest whitest and brightest" suddenly comes around and tries to redefine what a database management system is all about... Not talking about you!, I'm talking about Ms and others. Sybase included.

>
>Uh....if they address a need then they in fact do serve a purpose.
>

Nope. They might address the need of some for a database, but most of them do not serve the purpose of being database management systems at all. There is a difference in nature as well as in terms. Semantics, anyway.

>
>Temporary tables are a quick example.
>

Why do you think temporary tables are such a great help? What is it that makes them such a good idea or even so desirable? Genuine question: I never saw the need for one in many, many years of db design and coding.

Views as implemented by ORACLE have always solved my problems. Later, the dynamic views and the PL/SQL tables have eliminated any need for such a feature. Without even touching the performance and data management impact of having data tables cropping up around the place without proper storage control.

>
>Well...first off I shudder to think of a technical person actually believing
>marketing hype. Secondly how is it not a proper RDBMS? All of the stuff
>that seems to count from a design standpoint is there as it is on Oracle.

Nope. There is a little bit more to being a true database management system than just being able to cluster records around a key value (which basically means they are physically sorted by key).

Things such as:

• be able to match the database page size to the type and nature of data being stored. In ORACLE since V5, never in Sybase.
• be able to lock at row level for ANY volume of locks, without a serious impact on performance In ORACLE since V6, never in Sybase.
• be able to do a read-consistent access, as defined by Codasyl so many years ago. In ORACLE since V3, never in Sybase.
• not have writers blocking readers, as defined by Codasyl so many years ago. In ORACLE since I believe V3, never in Sybase.
• be able to keep a consistent relational data management structure for BOTH user data and database management system control structures (one of Codd's 12 rules for RDBMS). In ORACLE since day 1, never in Sybase.
• be able to use the same language for both database management and database data manipulation. Another one of Codd's 12 rules. In ORACLE since day 1, only of late in Sybase and still not complete.
• be designed from the ground up as a relational database system. ORACLE was, Sybase is only a port of the old Britton-Lee database machine OS, which wasn't even relational.
• use an industry standard DML. ORACLE with SQL since day 1 and of late with PL/SQL (based on Ada), Sybase still using that abortion called Transact-SQL.
• have a proper mechanism for implementing PK-FK relationships at database engine level. In ORACLE since V7, Sybase still has to use triggers.
• be portable. ORACLE has no match in this area. Sybase still only runs well in UNIX.
• be able to resize a column's max allowable size without forcing a re-design or a data unload/load. In ORACLE since day 1, try to change an integer cluster key column in Sybase to long integer and check what you gotta do...

And I could go on for quite a while. Some of the above have to do with database design, some with administration, some with performance. They serve merely to ilustrate my point: anyone can put together some code and call it a database, then proceed with heaps of marketing to make it stick.

But those who have been in IT for a little bit longer than the last release of MS software know that approach is flawed. That's why ORACLE tends to be the prefered choice for shops that know a thing or two about IT and want a database management system. As opposed to wanting a "database".

Of course, there is always simpler demands that can be addressed by things like Access and such. That's fine. Let's just not call them database management systems. Just databases, or "glorifed data editors", if you prefer.

Note that I didn't mention once ORACLE 8i. IMHO, this version of ORACLE is absolutely mind-blowing in the length and breath of features available to the designer, the coder and the DBA. In a class of its own and eons ahead of anything else in the market and I include DB2 here.

And nope, I don't work for ORACLE, haven't done so since 1989. Still using it, though. Still haven't found anything better.

Cheers
Nuno Souto
nsouto_at_nsw.bigpond.net.au.nospam
http://www.users.bigpond.net.au/the_Den/index.html Received on Thu Aug 31 2000 - 04:35:25 CDT