Results 1 to 8 of 8
  1. #1
    Join Date
    Jan 2006
    Posts
    74

    Unanswered: Oracle v's SQLServer

    Is there any up to date docs Oracle v's SQL Server. I'm trying to hold onto my oracle databases and mgmt want to move to SQLServer.

  2. #2
    Join Date
    Jun 2003
    Location
    West Palm Beach, FL
    Posts
    2,713

    Talking Google it.

    Is your Google broken? I got 229,000 hits.
    The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

  3. #3
    Join Date
    Feb 2003
    Location
    India
    Posts
    216
    there r too many similarities and equal number of differences in oracle vs sql server.
    the point should be why the management want a shift and why u want not....

  4. #4
    Join Date
    Jun 2004
    Location
    Liverpool, NY USA
    Posts
    2,509
    What do you want to do with the database. Oracle is much better on read consistency, hardware and O/S independence and sheer processing speed, but harder to manage. If they go to sql Server they are locked into WinDoze machines... IMHO not a good thing.
    Bill
    You do not need a parachute to skydive. You only need a parachute to skydive twice.

  5. #5
    Join Date
    Mar 2002
    Location
    Reading, UK
    Posts
    1,137
    Another good point is that Oracle and SQL server take very different approaches to locking so you will have to make a lot of changes to your apps if you want them to carry on working. Also Sql server developers often use stored procedures where you wouldnt in Oracle for performance so its not just migrating your data into sqlserver but potentially moving code from the app into stored procs.

    Alan

  6. #6
    Join Date
    Sep 2002
    Location
    Ohio
    Posts
    204
    I manage a DBA group that support Oracle, SQL Server and the Oracle Applications tech stack and we are now being asked to support MySQL. The answer to your question goes beyond functionality and performance of the databases themselves.

    When we have a new application that needs a database, we have a process that we follow to determine the best RDBMS to use for that application. Below is a summary of the questions we ask:

    1. If it's a vendor app, what RDBMS does the vendor develop with and do they support other RDBMS? We have tried to force and application to use an RDBMS that the vendor supports but doesn't develop against. It is always a painful implementation and we generally teach the vendor a thing or two about the RDBMS that they don't use in-house. It is generally easier to go with what the vendor knows.

    2. Which RDBMS is the team that is going to support the application most comfortable with? I do not want to force a developer that has been working with SQL Server for years to have to learn Oracle (or the other way around) just because it suits the DBA's.

    3. Does the application require special features that only exist in one RDBMS and not another? We had an application that on paper looked like it was a perfect fit for our DB2 on the mainframe solution. However, after deeper analysis, we found that the application relied on Oracle's Advanced Queing, for which their was no DB2 counterpart at the time. We had to use Oracle.

    4. Do we have space on an existing database server that the new database could fit into at minimal cost to the company? I am a big believer in server and/or database consolidation where it makes sense. We haved saved big bucks over the past 5 or 6 years through our consolidation effort.

    5. Finally, if everything else is equal on the technical front, which will option will cost the company the least amount of money?

    These are only a few of the questions we ask, but should be enough to make my point. For the vast majority of applications for which we support the database, they could use just about any RDBMS and be perfectly happy. They are not high volume, mission critical apps and do not use any of the database's advanced features. For these, we try to make the best choice for everyone involved. Having said that, there are also those apps that should clearly be SQL Server, or Oracle, or DB2 on the mainframe, etc.

    So, in summary, my point is that you need to take any Oracle vs. SQL Server comparison with a grain of salt, and try to determine what is the best path for your company. Also, as a last thought, do not forgot the learning curve for the developers, the DBA's and the server admins that comes with implementing a new database technology. Even if the database software may be cheaper, the overall cost to company may be higher of no one is familiar with the technology.

  7. #7
    Join Date
    Aug 2003
    Location
    Where the Surf Meets the Turf @Del Mar, CA
    Posts
    7,776
    Provided Answers: 1
    buckeye234,

    I applaud your post!

    I will say that MYSQL takes much less effort from a DBA perspective to support than Oracle takes.
    You can lead some folks to knowledge, but you can not make them think.
    The average person thinks he's above average!
    For most folks, they don't know, what they don't know.
    Good judgement comes from experience. Experience comes from bad judgement.

  8. #8
    Join Date
    Sep 2002
    Location
    Ohio
    Posts
    204

    Talking

    Quote Originally Posted by anacedent
    buckeye234,

    I applaud your post!

    I will say that MYSQL takes much less effort from a DBA perspective to support than Oracle takes.

    Thank you. I appreciate the applause. .

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •