Don't Overdo It, SQL Server

  • Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/hji/dontoverdoitsqlserver.asp

  • Nice article and I agree that MS should KISS.  That's what I find to be so great about it.  It is simple where you need it to be (like SQL tuning...it just works and typically doesn't require hints like the incredibly stupid, bug-laden Oracle optimizer), and yet offers enough tuning capability to run with the big dogs...and they're opening that up a bit more, which it a good thing.

    To clarify one of your points, in Oracle, a schema is not like a database, it is simply a privileged user that owns objects...whether they be tables, indexes, procedures, etc.  There is no definition of storage attached to a schema owner in Oracle, you define that on an object by object basis (unless you take the default tablespace of the schema owner).

  • "In my understanding, a schema in Oracle is like a database in SQL Server."

    I think a database in SQL Server would be more like a tablespace in Oracle. FWIW.

  • Nice article, but the editorial at the bottom was a bit out of place.

  • Nice article.Can you shed some light on how administrative tasks are done in sqlserver 2005 as compared to oracle.

    They say costwise oracle is more costly than SQLserver , is that true?

  • Let me put it this way.  I was a DBA on both for close to 6 years in a large investment company, and I can tell you this.  I was able to manage about 15 SQL Server databases but only 4 Oracle, and the Oracle ones took 75% of my time.

    I would only put warehouses on Oracle.  SQL has to prove they can do what Oracle's been doing for years.  The direction MS is going with partitioning, etc, is the right one, but they have to prove they can function on a 64 bit platform before I'd consider putting a TB warehouse on SQL Server.

  • Thanks for the comments, folks.

    To dma333: regarding what a schema is, you are right. As this article is geared more toward Sql Server DBAs, I thought using the database analogy is easier for the target audience to understand. I hear you about manageability issues with Oracle. I personally don't have much DW experience to add to your comment, but like you said, table and index partition and 64-bit will be very helpful in that regard.

    To Stephen: Actually tablespace is more like a filegroup in Sql Server. Like filegroup, a tablespace can have several data files.

    To Kevin: Yup, the editorial is a bit out of place here. This article grew out of a blog entry I had. It is appropriate to have a personal opinion at my own blog site, it may not be very appropriate for it to appear in a formal article.

    To nvb: regarding how common tasks are done on both platforms, that is really a loaded question. However, I blog regularly on my blog at http://www.HaidongJi.com. And that is a subject that I am personally interested in. I plan to blog more on it. In addition to Oracle and Sql Server, I will cover some MySql as well.

    As to cost and TCO, my personal opinion is that Sql Server is definitely cheaper. With multi-core servers becoming prevalent, that will be even more obvious. Sql Server pricing is based on number of sockets, regardless of how many cores you put in. Oracle, on the other hand, charge customers based on the number of cores the machine has. Of course, pricing changes all the time and big customers rarely pay the sticker price. It's kind of like Boeing and Airbus planes. I don't think anybody is paying the list prices.

  • i agree it was out of place but sometims its nice to highlight the greater scope of a company (and their philosophies). Bills' philanthropy would edge me towards his product(s) for that reason alone (plus I think SQL is great and getting better with age.). Keep it up guys!

     

  • Oracle schema and SQL Server 2005 schema are the same. But Oracle allows only one database per instance.

  • Yes and no.  In SQL 2005, a user can own multiple schemata.  In Oracle, a user can only own one schema.

    For example, in SQL 2005, user "x" can own schema "y" and schema "z."  So it can own two tables called "mytable" which could be referenced as follows: select * from y.mytable; select * from z.mytable.  As BOL states "Beginning in SQL Server 2005, users and schemas are separate, and schemas serve as containers of objects." 

    So really a schema is just another object owned by a user, which serves as a container for other objects.  In Oracle, the user and schema owner are one in the same.

Viewing 10 posts - 1 through 9 (of 9 total)

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