Re: L:ist - Can do/do better in MS SQL than Oracle

Lets be honest here folks. If you can do it in Linux, MySQL, Apache, and Star Office you have no business spending money on anything else. To do so is fiscally irresponsible.

If there are reasons why you need to spend money ... then you should do your best to get as much for your money as you can. If the criteria include stability, security, scalability, performance, 7x24, thousands of users, etc. Oracle is likely the best value for your dollar.

Daniel Morgan

Mike wrote:

> my penny and a half -
>
> I would add that a large part of your decision should also be based on what
> you plan to do with it. If you "need" multi-platform support and plan on
> working with or warehouse large amounts of data then most likely Oracle. If
> you're talking application support and transactions, it's probably a wash.
>
> Because Oracle is higly configurable you do/can spend a lot of time keeping
> an eye on it unless you give it a LOT of breathing room (i.e. disk space),
> especially if you deal with replication, hot backups and/or are in a 24/7
> shop. With either you must have a dedicated and consistent backup scheme
> with (RMAN as mentioned below or other) - but from my own experience, Oracle
> is much harder to recover when you have a disaster.
>
> If your budget is smaller or you are in a smaller shop - you don't have
> someone who can spend a LOT of time in DBA administration, then SQL.
>
> SQL DTS packages are very easy to use and build and does make data imports
> and exports very easy.
>
> As far as from a programming standpoint - I'd say it's a wash with VB and
> ADO - I know there are some in the community who say that Oracle is a tough
> fit with VB - but I've had no issues or problems with it and Oracle has been
> my main back-end for four years. SQL is easier to program for in ASP - that
> much I will say.
>
> One note, the ongoing cost of support, maintainance and keeping the
> databases tuned and working efficiently is the very reason we are moving
> away from Oracle. The economy of maintaining several databases in a
> production enviroment when companies are trimming staffs, well, SQL is
> easier to manage in that regard.
>
> That's all I have to say.
>
> "Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote in message
> news:3ca2e7b7$0$225$ed9e5944_at_reading.news.pipex.net...
> > My 2 cents (from an Oracle viewpoint)
> >
> > "sandiyan" <sandiyan_at_yahoo.co.uk> wrote in message
> > news:69e9c64b.0203270941.5b05708e_at_posting.google.com...
> > > I am been tasked to get a list:
> > >
> > > - that contain points that MS SQL will support but not Oracle...
> > >
> > > - that contain points that MS SQL will do better than Oracle...
> > >
> > > Points can be based on:
> > > Operatability...(from a DBA point of view)
> >
> > MS Management tools and wizards are far in advance of those that Oracle
> > offers. The plus side is that tis pretty much allows anyone to manage a
> DB,
> > of course the downside is it pretty much allows anyone to manage a DB. On
> > the other hand Oracle is highly,highly configurable in a way that SQL
> isn't.
> > > Backup/Restore
> >
> > Oracle ships out of the box with a product that allows you to backup only
> > changed blocks from datafiles (RMAN). As far as I know MS doesn't provide
> > this level of functionality which will help massively on very large
> > databases.
> >
> > > Transact vs PL SQL language
> >
> > pays your money you takes your choice. Oracle also supports java within
> the
> > DB - the jury is out on how good an idea this is.
> >
> > > Cursors
> > > Security
> >
> > Is almost always a configuration issue not a technology issue. Oracle is
> > probably technically ahead and of course runs on platforms other than NT.
> >
> > > Instances/Clusters(Real Applicatin clusteres)
> >
> > Oracle runs well on decent high end clustered systems. MSSQL runs on NT
> > clusters. Oracle clustered boxes are always contributing to the
> performance
> > of the system. RAC looks a very very good product.
> >
> > > Performance
> >
> > is 80% down to good initial design. Most of the rest is then down to
> > codeing. the fixes will be application specific. Bear in mind that in
> Oracle
> > select statements will *never* wait for an insert/update to complete and
> > vice versa. (unless you choose to so cripple them).
> >
> > > etc...
> > >
> > > I have got meeting with Oracle consultants and need some points so
> > > that I can judge whether it is really worth moving to Oracle...
> >
> > It'll cost you :-(
> > >
> > >
> > > Thanks,
> > > NM
> >
> >
Received on Thu Mar 28 2002 - 18:10:16 CST