Re: Oracle vs SQL server

Just my two cents:

Oracle's main advantages over SQL Server are scalability and maturity. Although I don't keep track of the SQL Server problems as meticulously as Richard does, there are enough of them to suspect that for Microsoft the database server business is a side show that does not get enough attention. The main problem in terms of scalability is that you are locked into NT as your only platform. Although this might not seem like a problem in your current situation, databases are normally planned for the long term. And I'd rather know that I can put in new hardware and a different operating system any time I want to.

As for the example of running a team without a DBA, I don't think that's a good idea no matter with RDBMS you are running on. Yes, SQL Server might be able to hide things from you a little more. But that only means they'll come back to haunt you later. Plus, Oracle's GUI interface has come a long way from the clunky 7.1 days...

As I said, just my 2 cents ;-)

Klaus Sonnenleiter
The Media Machine

Richard wrote:

> >> > This is not an attempt to start a flame war. Or a mine is better
> contest. I was
> >> > recently reading an article comparing the two databases and the author
> said
> >> > both programs were good and that each could be used various
> situations
> >> > interchangeably but the author said this is true in only 95% percent of
> the
> >> > cases. My question is what area (mainly the 5%) is beyond SQL
> server's
> >> > abilities. I apologise if this questions has been asked and answered.
> Thank you
> >> > in advance
> >
>
> Sounds like a useful review !!!
>
> I have no experience of SQLServer 7, but with 6.5... there are some
> problems. Here's a short list based on my few months experience with it
>
> - if you redefine a view, stored procedures will access the old view
> until recompiled
>
> - TSQL rarely indicates the location of synatx errors
>
> - two hints are available compared to Oracle's 20+
> (can't remember the exact number)
>
> - if you rename a table using the GUI, bad things can happen to the data
> dictionary
>
> - BCP (flat file export) places a blank line at the end of each file.
> This had
> had to be removed manually (no "sed" available on NT) before data
> transmission
>
> - space allocation via the GUI doesn't always work and sometimes has no
> effect
> (no error, no effect, no nothing)
>
> - when a TSQL program runs into an error situation (eg called procedure
> not available) it continues - committing the "transaction" and
> leaving the database
> in a potentially corrupted state
>
> - there's no way of aborting from within TS procedure (that I know of),
> so if the
> program encounters an error N procedure calls deep, the only way to
> exit safely
> is to pass a failure flag back through each call - and to include
> messy
> handling logic
>
> - there're no user defined functions available (I believe there're
> possible in v7)
>
> IMHO, general consensus in the industry seems to be that SQL Server is not
> up to handling VLDBs (large databases) and data-warehousing operations.
> More specifically, I have serious doubts as to whether SQL Server can handle
> ad hoc or computer generated SQL as supplied by client analysis tools in
> decision support/warehousing situations.
>
> Thing is, despite it's flaws and pitfalls (every few weeks I come accross a
> web page showing unandled SQL Server errors), SQL Server is probably easier
> to get started with than Oracle, and is simpler for GUI heads to administer.
> Sooo - I'd consider using it if I was a small company without a dedicated
> database and/or programming team (ie running a supplied app.) and if I
> wasn't a biased Oracle programmer.
>
> ; >
>
> Regards,
>
> Richard Gowan
Received on Sun Jun 13 1999 - 09:52:51 CDT