Re: Is Oracle deliberately difficult?

"Nuno Souto" <nsouto_at_nsw.bigpond.net.au.nospam> wrote in message news:39ae2932.2044135_at_news-server...
> 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.
>

We'll have to agree to disagree here. I dislike elitism. In my mind elitism of one product or another doesn't solve anything and definitely can cause problems. Its like the Mac vs PC thing. Use the tool that best stuits you. Length in any industry means one thing and one thing only...you have a lot of experience. As someone whos had 25 years in the industry I'd think you'd agree the 'latest whitest and brightest' should only be so once they've been proven so. Marketing means nothing except to the marketers (and people who dont know any better).

> >
> >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.
>

I've always found them handy in years of coding. Maybe its preference or what one is used to but I like them.

> 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.
>

The tables only 'crop up' for the length of the code that creates them...thats the point. If they didn't act that way they'd be "work tables". I personally loved having the ability to create tables and use them on the fly however I wished without having to worry about the clean-up. Maybe its 6 of one half-dozen of the other on this issue. I see your points and they're valid.

>
> >
> >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).
>

Heh. Pretty complete list :) Even if you are being elitist at least you're thorough ;)

> 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.
>

This is possible in SQL Anywhere (which isnt Adaptive Server of course).

> - 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.
>

Is there performance data out there for Sybase vs Oracle in row level locks and volume?

[snip]

> - 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.
>

Example please.

> - 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.
>

Uh....PL/SQL and TransactSQL have nothing to do with any standard (obviously). Transact-SQL worked as well for me in the past as PL/SQL does now. I'd hardly classify it as 'an abortion'. PL/SQL may be based on Ada but that means pretty much nothing for the majority of programmers out there. I highly doubt that Sybase will switch from Transact-SQL at this point. Dont see why they should. It works fine.

> - be portable. ORACLE has no match in this area. Sybase still only
> runs well in UNIX.
>

Only used Sybase on UNIX so I can't comment there. Oracle definitely is available on many platforms but are they all equal to the task as the Solaris version?

> - 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...
>

Never had to do this before so I can't comment.

>
> 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.
>

Apparently the market agrees as Sybase has a miniscule share but that seems to have just as much to do with their management as anything else.

> 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".
>

According to the polls DB2 and Oracle are running neck and neck in marketshare. Apparently a lot of people don't think Oracle is the end-all.

> 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.
>

The market isnt agreeing. Thats why DB2 is just as popular. Oracle 8i is pretty impressive though.

Jason Received on Thu Aug 31 2000 - 18:16:33 CDT