SQL Server VS. Oracle
-
quote:
In response to your last statement regarding milliseconds, this is exactly what I'm talking about. Everyone has something that somehow makes them like on product over another, and this means that any nitpicking done on details on the other will always be made from a viewpoint that "this is how it's done in my product, so therefore that is the best way to do it".
--
Chris Hedgate @ Apptus Technologies (http://www.apptus.se)
I basically agree that anything can be done in either one one way or another. However, there have been statements in this forum about SQL server not scaling for very large databases and I wonder if there is any truth to this.
I worked for a telecommunications company where they processed 100's of gigabytes of call data using SQL server. Can anyone tell me where specifically they have encountered a scaling problem and how it manifested itself?
-
quote:
I basically agree that anything can be done in either one one way or another. However, there have been statements in this forum about SQL server not scaling for very large databases and I wonder if there is any truth to this.I couldn't agree more. In my opinion, these statements are either based on old experiences or on SQL Server instances not very well configured. Even though the TCP-tests may not be exactly what we encounter in reality, they still show what can be done, and the facts there speak for themselves. Who actually has the highest rating at any one time is not interesting to me, the fact that both DB2, Oracle and SQL Server are represented show that they can all scale if used correctly.
--
Chris Hedgate @ Apptus Technologies (http://www.apptus.se)
-
quote:
I couldn't agree more. In my opinion, these statements are either based on old experiences or on SQL Server instances not very well configured. Even though the TCP-tests may not be exactly what we encounter in reality, they still show what can be done, and the facts there speak for themselves. Who actually has the highest rating at any one time is not interesting to me, the fact that both DB2, Oracle and SQL Server are represented show that they can all scale if used correctly.
--
Chris Hedgate @ Apptus Technologies (http://www.apptus.se)
exactly.....
-
Through experience with both I feel that Oracle is more forgiving to a poorly designed DB.
-
quote:
Through experience with both I feel that Oracle is more forgiving to a poorly designed DB.Now this is interesting. Do you see this as a good thing or a bad thing? Personally, I have no idea if it is more forgiving or not, but if it is I would see it as a bad thing. Just as the way Microsoft (and Netscape and the others, but IE was the worst) made everyone start writing lousy HTML because IE was so forgiving. Bad database design shouldn't work at all, that would make me happy.
--
Chris Hedgate @ Apptus Technologies (http://www.apptus.se)
-
Capital One has an Oracle 6boxcluster, 4-way app. (24 CPUs)
SQL Server couldnt handle certain queries.
All the CC data i think.
-
Chris
I'm with you. Begin forgiving of bad database design is not in the "plus" column for me. Who wants to deal with optimizing or otherwise cleaning up someone else's mess? Unless, of course, there are big consulting bucks to be made in doing so...
Vik
-
quote:
Capital One has an Oracle 6boxcluster, 4-way app. (24 CPUs)SQL Server couldnt handle certain queries.
All the CC data i think.
Although you may be entirely correct in your statement, I would be hard pressed to believe it. I just finished a contract for a VERY large company importing credit card data from hundreds of sources, containing millions of transactions from thousands of point of sale terminals in hundreds of different formats, and a single two processor, 2 gb ram box with standard raid array drive system, is handling it easily. Of course, I designed the system from the ground up, so was able to write it the way I wanted, and that made all the difference in the world to me, as I have seen systems that no amount of hardware would handle "easily".....
Oh, and as far as bad design goes....
The only thing in the world that is worse than outright errors, in databases, is poor design. At least with errors you are forced to fix them. With poor design, the idea seems to be that "there is not enough time to go back and re-architect it" or the famous, "What, its working isn't it?" These types of issues tend to not get the attention they deserve, because nothing is actually broken, it just runs like sh?t.....making a dba's nights and weekends awful. And so long as the company can limp through, and place the burden on the production dba's to keep it running regardless, it will never get changed. SO, in my opinion, the man who wrote it should support it for a couple months, at least, and I bet he/she wouldn't do it again. If he/she does, it's time for some good old home style justice. (In texas, that means a shotgun....
)Edited by - scorpion_66 on 03/26/2003 4:09:46 PM
-
Then, tell you what guys:
its MySQL and Good Design from now on!
Damn the vendors!
-
I develop in both environemnts. Usually, I remain a couple of weeks in one environment to reduce the number of transition errors. It helps to look at problems from 2 very different implementation angles.
SS wins easily as far as ease of use is concerned.
PL/SQL is a fully fledged programming language, just a bit quirky.
SS's trigger environment (after statement) is a poor cousin to Ora's before/after statement and row triggers.
SS panicks early and locks up a table if more then a handfull of rows are updated. Ora is more robust when it comes to multiple transactions on one table.
It's horses for courses.
Win
-
quote:
Then, tell you what guys:its MySQL and Good Design from now on!
Damn the vendors!
Ehm, since you didn't include any smileys or anything I take it you actually mean this? Sorry, but you can't do good design with MySQL. Actually, it shouldn't even be allowed to be called MySQL until the latest version 4 where they finally support subqueries.
--
Chris Hedgate @ Apptus Technologies (http://www.apptus.se)
-
I work with both SQL Server and Oracle. Oracle overall has a higher TCO. I mean a Server SQL DBA fetches around $70,000 and a Oracle DBA yanks about $85,000. Training costs are HUGE for Oracle training since it is done ala cart whereas with SQL Server it is packaged together quite nicely. I believe Oracle intentionally makes it's software user-unfriendly. For example in T-SQL if you want to display text while running a procedure then the command is "print <text>". In oracle you have to first go into the DB and turn the option "SERVEROUTPUT" on and then the command to display text is "DBMS_OUTPUT.PUT_LINE <text>" What the heck is up with that?
Now where SQL Server beats Oracle hands down is in ETL capabilities and functionality. DTS is THE BOMB!!! Oracle has something similar but it is a add-on and it is as complicated as DTS is simple. 1 yr ago in my shop we spend $100,000 on a ETL software called SAGENT that was suppose to beat DTS hands down. Well if you look around the shop at the tool of preferrence when you anyone is moving data it's DTS!
-
As a DBA with eight years' Sybase, four years Oracle, and three years' SQL Server (a.k.a. "Son of Sybase") experience, herewith my two cents...
I'm not a partisan for either DBMS, but appreciate the pros and cons of each. I think the differences between the two can be summarized thusly: Oracle is more powerful and more flexible than SQL Server, but more expensive and harder to use. These differences are reflective of the differences in the business models. Oracle is first and foremost a vendor of consulting services -- most of them sold to puzzled Oracle DBMS users -- and have thus had little incentive (until recently) to integrate their products and make them easier to understand and use. Microsoft is first and foremost a vendor of operating systems, selling applications like SQL Server mainly so that you'll buy their operating systems; their incentive is therefore to sell you something that's easy to install and easy to use, integrates well with existing (Microsoft) apps, and has sufficient power for the mythical "average user".
1. I think the definitive difference that renders Oracle (sorry, you SQL Server guys) the more robust DBMS is its approach to locking. Oracle is able to play a convincing "shell game" between the committed and uncommitted portions of the database, providing each connection with a read-consistent view without using READ locks. Since SELECT statements usually comprise the preponderant transaction costs in most database installations, this is an enormous boon for Oracle.
2. One correspondent on this thread says, you'd be surprised, Oracle is not that much more expensive than SQL Server... but then went on to speak mainly about licensing costs. That's only part of the story -- unfortunately for Oracle. Oracle DBAs are more expensive than SQL Server DBAs, and typically -- for the same size of project -- you need twice as many of them. Labor costs favor SQL Server, hands down.
3. Many have asserted that Oracle's PL/SQL is more powerful than SQL Server's T-SQL. Well, "power" is often a subjective term; I think we're better off talking about traits. Here are some differences between their respective traits to think about:
a. Error handling. Some have already remarked on the power of Oracle's error handling (i.e., BEGIN...EXCEPTION...END blocks), but this perspective still isn't complete without a thorough thrashing of SQL Server's abominable error handling. Using the EXCEPTION block, the Oracle PL/SQL coder ultimately decides which errors are trapped and processed around, and which ones bump you all the way back to the OS. With SQL Server, the DBMS itself makes those decisions, and if it decides to bump you all the way out, you have no way to override its judgment. (Not to mention that Oracle error messages are far better documented.)
-
(con't from previous post)...
b. Triggers. Both databases have "AFTER" triggers, but only Oracle has true "BEFORE" triggers; SQL Server has only its weak-sister imitation, the "INSTEAD OF" triggers. Also, though SQL Server triggers are statement-level (i.e., they fire once for each triggering statement), Oracle has optional row-level triggers (i.e., they fire after changing each row). Consider what this means: In T-SQL, there are circumstances under which, inside a trigger, you cannot deduce, after the fact, which changes have been applied to any specific row. For example, what if a transaction has modified the value of a key column for several rows? (I'm not saying business should be done that way, only that sometimes it is done that way.) Good luck trying to match the 'before' and 'after' picture -- what JOIN criteria can connect the appropriate rows in the 'INSERTED' and 'DELETED' pseudotables? But not a problem, for an Oracle row-level trigger.
c. Backup/recovery. Winner: SQL Server. Doing hot backups is a cinch in T-SQL, but Oracle requires OS-level backups and the implementing the backup/recovery strategy can be a full-time job for one DBA in an Oracle shop.
d. Programming ergonomics. No clear winner. Oracle's advantages include packages, arrays ("PL/SQL tables"), better data-typing, referential data type definitions (e.g., defining a variable not explicitly, but to be defined exactly like another column or variable); more system functions; loads of canned packages; easier-to-decipher metadata. T-SQL's advantages include a more flexible LIKE operator (Oracle can't use brackets to spell out pattern options for a single byte), extended stored procedures, temp tables, and far easier-to-use dynamic SQL options.
e. I/O Ergonomics. SQL Server finally comes into its own. Frankly -- to use a metaphor that will never put me in the good graces of any English majors -- I/O in Oracle is a pregnant female dog. Unlike Oracle, T-SQL procedures can return results sets, which -- ANSI-compliant or not -- is extremely convenient. SQL Server's T-SQL talks easily with the OS; Oracle PL/SQL does so only grudgingly and with great effort -- and I am not aware of anything to match T-SQL's 'xp_cmdshell'. BCP is not as powerful as SQL*LOADER, but it's easier to use and works for data going in, or data coming out, of the database (SQL*LOADER only works for data going in). Oracle's tools seem poorly integrated, relative to SQL Server's. TOAD works as well as Query Analyzer, maybe even better, but it's a third-party product. T-SQL and ISQL are seamlessly integrated; not so with PL./SQL and SQL*PLUS. I can't comment on the alleged advantages of DTS, since I seem to be alone among SQL Server DBAs in my abhorrence of it, but if you like DTS, that's another plus for SQL Server.
-
Sorry, Lee Dise, but I disagree on the triggers. The joining of the before and after pseudo tables is done on the primary key in any case, and you will always have matching rows for the comparison. If your table does not have primary keys, your violating a golden rule to start with, and the functionality loss thereof cannot be blamed on the triggers.
To expand on this, I would say that handling it on a row by row basis actually violates set based thinking, and goes back to a step by step processing methodology. As we know, both SQL and Oracle are set based creatures, and just the thought of taking a RDBS and making it act like an application gives me goosebumps.
On the cost point for labor, while I agree that the average that happens at most companies agrees with your statement, my own personal point of view is from making roughly 1.5 times the money of the Oracle guys I work with, as A SQL guy and comparing at an equal level of experience in our professions. I can tell you that it's more in experience and ability than platform. From what I've seen, Oracle guys require more training to perform the same functionality. This means that a company could hire two persons to perform the same job on the different platforms and the oracle guy would most likely have twice the training of the SQL Guy. Hence, an uneven comparison. Now, make a comparison of two guys of equal experience and training and the tables turn somewhat. I will grant that the company may not need that level of skill in their SQL Server guy (it's not required), but I will also state that they would greatly benefit from it. It's seldom that I find myself re-engineering an Oracle database, and quite often I find myself doing it with SQL Server. The point here being that were the company to hire a SQL guy as competent as the Oracle guy, would they have to re-work their schema'a due to poor design? So, by the time a company has to redesign an app a couple times, was the SQL guy they hired really cheaper? In terms of dollars the person took home at the end of the week, yes. In terms of cost to the company, No Way. Hiring the more expensive SQL guy would cut their redesign costs by a good bit. And, of course, this places the costs of the SQL guy up there with the costs of the Oracle guy or even beyond. This is quite often overlooked due to the "How cheap can I get them mentality.", where of course you CAN get cheaper SQL guys than Oracle, but do you really want them.
As far as the rest, I think you make some excellent points. Especially on the business models.
Viewing 15 posts - 61 through 75 (of 96 total)
You must be logged in to reply to this topic. Login to reply