Re: Is Oracle deliberately difficult?

"Nuno Souto" <nsouto_at_nsw.bigpond.net.au.nospam> wrote in message news:39afa5c1.857559_at_news-server...
> On Thu, 31 Aug 2000 18:16:33 -0500, "Jason Kratz"
> <jkratz_at_rctanalytics.debug.com> wrote:
>
> >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).
>
> Absolutely in agreement here.
>

Hey hey! We agree on something ;) Good to see cooler heads prevail here (mine mostly). Good conversation is hard to find.

>
> >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.
>
> I see what you mean. One thing that always makes me cringe as a DBA
> however, is the ability in a database engine to create ad-hoc tables
> of any given size. Bad news for space management, in any engine.
>

Yes. This is a very valid point that I honestly didn't think about. In my background temp tables were always very small but that might not necessarily be the case everywhere.

> They may be indeed useful, although as I said I never needed them.
> But they sure will upset any DBA taking care of a sufficiently large
> database.
>

Well...nobody ever complained from the DBA team but that doesn't necessarily mean anything either ;)

> >
> >Is there performance data out there for Sybase vs Oracle in row level
 locks
> >and volume?
>
> I dunno. What I do know is that I never felt the need to limit number
> of row locks in ORACLE since they have been around. In Ingres it was a
> big problem with the stupid lock escalation and in Sybase they never
> existed (page locks only). Curious to see what will happen to SS7 and
> their "dynamic row locks"...
>

Page locks sucked *majorly* in Sybase 11.0. What a pain in the ass they were as a developer. Sybase promised row-level locks for 11.5 and didn't deliever them until 11.9 which is a joke (well...AFAIK). As I use Oracle now I never got a chance to see how well it worked in Sybase ASE ;)

> >> - 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.
>
> SQL everywhere. Use it to manipulate data as well as to examine and
> analyze the dictionary. This is only possible in databases where the
> dictionary itself is stored in tables, just like any other user data
> (of course, under lock-and-key!). When you gotta stray off SQL and go
> back to a proprietary language (be it T-SQL or whatever) in order to
> do basic administration checks, something is very wrong with the
> "RDBMS" engine!
>

Hmm....maybe I keep thinking of SQL Anywhere here then. SQL Anywhere uses tables to store info on objects just like Oracle does. I'm not sure quite what level it goes down to though (like the free extents tables on Oracle). I see your point though.

> >
> >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.
> >
>
> Well, the problem is that to do anything useful in Sybase, one has to
> resort to T-SQL. PL/SQL is not absolutely necessary in ORACLE, just
> an extension that is a nice to have. But most DBA stuff and app
> design stuff can be done using basic SQL and basic database features.
>

This is also very true. I guess I think of PL/SQL being necessary just because its there. But then again a PL/SQL engine is available in their development tools as well (dont get me going on those btw ;)

> >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?
>
> Yes, very much so. VMS (not as important nowadays), NT (pretty much
> solid, although performance doesn't match UNIX. But that is NT, not
> ORACLE), MVS (yes, the big iron!) and just about any flavour of UNIX
> you care to mention. Plus a few scattered proprietary OSes still out
> there.
>

The performance definitely isnt there on NT ;) Thats what we use here and its a pig.

[snip]
>
> >
> >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.
>
> In a way, yes. If they had bit the bullet ages ago and re-designed the
> product top-to-bottom to make it a true RDBMS, they wouldn't have the
> problems they have now. Instead they did the usual "hit-and-run" :
> poo-poo the competition and milk the old Britton-Lee code for all its
> worth. It's got limits and they hit them...
>

This seems to be the case everywhere these days ;)

> >
> >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 it isn't. And thank God for that or else this industry
> would be pretty boring. They can't match the features in 8i and they
> won't be able to do so for a while but they have a solid, well thought
> out product with all the necessary base features. So they are serious
> competition. Still nowhere near as portable as ORACLE but it will get
> there.
>

DB2 is just too weird to me. I really don't like the way stored procs and the like are handled there. We considered DB2 and I'm glad we went with Oracle instead.

> >>
> >
> >The market isnt agreeing. Thats why DB2 is just as popular. Oracle 8i
 is
> >pretty impressive though.
> >
>
> Pardon? I reckon the market IS agreeing. Fact is the only two really
> serious RDBMS products in the market are the only ones remaining in
> serious contention.
>

Well...my comment was about Oracle being the end-all and the market not agreeing.

Jason Received on Tue Sep 05 2000 - 10:36:15 CDT