Which is better and Why.?

  • Dear All,

    I have a question.

    Long back when I started learning SQL Server-2000, somewhere I had read that "SQL SERVER lies between ORACLE and MS-ACCESS" (in terms of the amount of data it can handle mainly). Yesterday while having coffee, I heard the same again from one of our junior navision developer. I said that it's history and SQL server with it latest versions can hanlde many terrabytes of data now and it's as good as oracle.

    Thought I said so I am not sure whether I am right or not.?

    Is SQL Server as good Oracle.? Which is better and Why.?

    I would like to hear your opinion on this.

  • MS SQL Server is the best. Period.

    but......

    if you are an Oracle Dba, Oracle would be the best.

    Each to his own.

    This is a question that can only truely be answered with physical test and performance comparisons.

    My personal opinion is that none is better than the other just because the papers say so.

    :hehe:

    -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    This thing is addressing problems that dont exist. Its solution-ism at its worst. We are dumbing down machines that are inherently superior. - Gilfoyle

  • Just to summarize and answer the question being asked right up front...

    If you have people that can write good code in either, both Oracle and SQL Server are very, very good at handling huge amounts of data with some very high performance.

    I've done both Oracle and SQL Server as a developer. Personally, I find it a lot easier to develop good code in SQL Server but that's just my opinion. The other thing that I've found is that cost of ownership both in the short term and the long term is less expensive with SQL Server. I'll admit that I've not yet written code that can run the stock markets of the world, but I've found no problems writting code for large companies that require a Tera-byte or more for each major server they operate.

    Product wise... Oracle appears to be just a bit more stable in that they don't come out with a CU every (so it seems) 30 seconds or so. They also don't seem to deprecate features that will cause old code to break as much. Again, just an opinion, but it seems that there's a whole lot more to know about Oracle both as a "Ninja" developer and, especially, as a "Ninja" administrator. That's part of the cost of ownership... Oracle DBA's and some Oracle Developers seem to get paid a lot more.

    As a Developer... I like SQL Server better simply because I like the extensions beyond "pure SQL" better. For example, SQL Server has an UPDATE statement that has a FROM clause that makes it super easy to do joined updates. With the earlier versions of Oracle (before they came out with MERGE), each joined UPDATE had to be riddled with correlated subqueries both in the SELECT list and the WHERE clause to make it work properly. Another couple of examples is that I can do variable "overlays" in a set based manner where Oracle requires a loop and, although Oracle has a thing called a "Temp Table", the Temp Tables in SQL Server are a lot more useful IMHO. I also don't like the fact that, even after all this time, you're forced to abbreviate object names and use underscores because no object name can be longer than 30 characters and when you gen the code to create an object, the default for Oracle is to gen it all in upper case (the default is a case sensitive server which I think is terrible... again, personal opinion).

    There are other things that personally bug me about Oracle like having to build a "Reference Cursor" to pass a result set to a GUI instead of just doing a SELECT. Again, that doesn't bother folks who are skilled in the Oracle arts.

    The myth... One of the myths surrounding Oracle is that it is "optimized" for procedural code (ie: Cursors, While Loops, and other forms of RBAR). I never found that to be the case... set based code beats RBAR even on Oracle. My problem is that, because of some of the things I've mentioned above, it's more difficult to write good set based code in Oracle. Heh... even their triggers force you to write RBAR and then use the clause "FOR EACH ROW" to process multi-row INSERTs, UPDATEs, and DELETEs.

    Features... Oracle does have some handy features (in other peoples opinion, not mine), though. I forget what they call it in Oracle, but you can easily datatype a parameter for a stored procedure based on the datatype of a column in a table. That does two things... reduces the chances of having a bunch of implicit conversions take place because the developer chose incorrectly and, if the datatype for the table column ever changes, the datatype for the parameter will auto-magically change. Oracle also has much more extensive handing of date formatting (ummm... do it in the GUI, please) and Hierarchies (although multi-million row Hierarchies are quite easy in SQL Server if you know how to use "Nested Sets" and the set based conversion from the "Adjacency List" to the Nested Set")

    Now... all that being said, I have to admit that I "cut my teeth" on SQL Server and not Oracle so I'm a bit prejudiced. There are people out there who have also used both DB engines and they'll swear that Oracle is much better. For them, it may very well be. I'll also say that, having done both, I have a huge dislike for Oracle and PL/SQL and will do everything in my power to never work in an Oracle shop ever again. I don't even like "mixed" environments where both DB engines are available. Heh... No hate mail, please... it's just my opinion.

    Heh... sorry... I got carried away and deviated from the subject question a bit. My recommendation is to ask the same thing on an Oracle forum and see what I mean when I say the answer to your question truly is "It Depends". [font="Arial Black"]If you have people that can write good code in either, both Oracle and SQL Server are very, very good at handling huge amounts of data with some very high performance.[/font] People that like Oracle will be just as opinionated (and maybe more :-P). On the subject of usability at the personal level, the only way to truly find out for yourself is to do both for a while because I agree with that which has previously been stated... "papers" on the subject tend to be as biased as much as my opinion above and the opinions that people will also render on this very thread.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I'll start by asking this, define better.

    I have not had the opportunity to with Oracle. I have been working with SQL Server since version 6.5. I'd say this, each has their place, just as the numerous OS's that exist.

    I enjoy working with SQL Server and find it a very stable and well performing platform.

  • Main thing I have read (and I work with Oracle people) is that some features "built into" SQL are built in to Oracle, if you buy them first 🙂

    http://itknowledgeexchange.techtarget.com/sql-server/sql-2008-r2-is-pricy-but-so-is-that-other-database/[/url]

    This article speaks on the pricing part (broad overview).

    Shawn Melton
    Twitter: @wsmelton
    Blog: wsmelton.github.com
    Github: wsmelton

  • Joy Smith San (4/7/2010)


    "SQL SERVER lies between ORACLE and MS-ACCESS" (in terms of the amount of data it can handle mainly).

    http://www.brentozar.com/archive/2010/02/top-10-reasons-why-access-still-doesnt-rock/[/url]

    Shawn Melton
    Twitter: @wsmelton
    Blog: wsmelton.github.com
    Github: wsmelton

  • Features like Materialized views, partitioned tables are not matured in SQL Sever as compared to Oracle. Inbuilt/System functions are more rich as comapred to SQL Server.

    For large databases this turns to be limitation some times for SQL Server.

    SQL Server is easy to develop and maintain.

    Cost is very less as compared to Oracle.

    Provides many features free of cost along with database server. i.e. SSIS, SSAS etc.

  • Oracle is a lot more expensive and i don't remember all the features, but it has some features that let it scale higher than SQL Server. I think the geo features that SQL 2008 had, first came out in Oracle.

    Oracle is also mostly deployed on Solaris/Sun software/hardware. expensive but they tend to be more stable than Windows. we have some Sun servers and i can't remember the last time they needed a reboot. not 100% sure but I think that Sun/Oracle SPARC CPU's can handle a lot more threads than x86 CPU's

  • Oracle's recent marketing slogan certainly beats anything Microsoft every cooked up:

    "ORACLE...Software...Hardware...Computers."

    Can't wait till CocaCola gets on that bandwagon

    "COKE ...Pop...Can...Beverages."

    -MarkO

    "You do not really understand something until you can explain it to your grandmother" - Albert Einstein

  • molson-927659 (4/9/2010)


    Oracle's recent marketing slogan certainly beats anything Microsoft every cooked up:

    "ORACLE...Software...Hardware...Computers."

    Can't wait till CocaCola gets on that bandwagon

    "COKE ...Pop...Can...Beverages."

    Sorry...I am not able to make anything out of it. Can you please clarify what does it mean ?

    Thanks.

  • I work in a multi db platform environment. We use both SQL Server and Oracle. I'm just a newbie when it comes to Oracle administration, and am mid-level with SQL Server administration.

    My supervisor, who is a strong administrator in both SQL Server and Oracle, has told me that with Oracle, you can "scale out" by adding more servers to a cluster and Oracle will split the workload between the servers. (If properly configured, of course.) With SQL Server, you are limiting to "scaling up", meaning to handle a larger workload you have to buy hardware that is faster and more powerful.

  • Joy Smith San (4/12/2010)


    molson-927659 (4/9/2010)


    Oracle's recent marketing slogan certainly beats anything Microsoft every cooked up:

    "ORACLE...Software...Hardware...Computers."

    Can't wait till CocaCola gets on that bandwagon

    "COKE ...Pop...Can...Beverages."

    Sorry...I am not able to make anything out of it. Can you please clarify what does it mean ?

    Thanks.

    Humor...

  • Bill Kline-270970 (4/12/2010)


    I work in a multi db platform environment. We use both SQL Server and Oracle. I'm just a newbie when it comes to Oracle administration, and am mid-level with SQL Server administration.

    My supervisor, who is a strong administratior in both SQL Server and Oracle, has told me that with Oracle, you can "scale out" by adding more servers to a cluster and Oracle will split the workload between the servers. (If properly configured, of course.) With SQL Server, you are limiting to "scaling up", meaning to handle a larger workload you have to buy hardware that is faster and more powerful.

    I think it's called a RAC cluster and only works on Linux or whatever the Beowulf cluster software works on.

  • Bill Kline-270970 (4/12/2010)


    I work in a multi db platform environment. We use both SQL Server and Oracle. I'm just a newbie when it comes to Oracle administration, and am mid-level with SQL Server administration.

    My supervisor, who is a strong administratior in both SQL Server and Oracle, has told me that with Oracle, you can "scale out" by adding more servers to a cluster and Oracle will split the workload between the servers. (If properly configured, of course.) With SQL Server, you are limiting to "scaling up", meaning to handle a larger workload you have to buy hardware that is faster and more powerful.

    I'm not a Systems DBA but I believe that SQL Server allows for a thing called "Federated Servers" that does just that.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden (4/12/2010)


    Bill Kline-270970 (4/12/2010)


    I work in a multi db platform environment. We use both SQL Server and Oracle. I'm just a newbie when it comes to Oracle administration, and am mid-level with SQL Server administration.

    My supervisor, who is a strong administratior in both SQL Server and Oracle, has told me that with Oracle, you can "scale out" by adding more servers to a cluster and Oracle will split the workload between the servers. (If properly configured, of course.) With SQL Server, you are limiting to "scaling up", meaning to handle a larger workload you have to buy hardware that is faster and more powerful.

    I'm not a Systems DBA but I believe that SQL Server allows for a thing called "Federated Servers" that does just that.

    Correct, with a smallish update. Oracle chose to combine their DR and their HA options into a single item (RAC); Microsoft sees the two as having competing priorities, so it split the two into two separate features (clustering and Federation).

    So - in a sense, RAC on Oracle = Clustered Federated servers on SQL Server. And that's without getting into the interesting list of limitations on both sides of the fence with the implementation.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

Viewing 15 posts - 1 through 15 (of 33 total)

You must be logged in to reply to this topic. Login to reply