Fog Creek Software
Discussion Board




SQL Server - Up or Down?

Is MS SQL Server really a "Declining technology"?

Lets keep in mind the SQL Server 2005 coming out in January.

Raju Patel
Wednesday, August 18, 2004

Yes MS SQL Server is a declining technology.  If you are gonna pay to play use Oracle.  If not then use MySQL.  Where does that leave MS SQL Server?  Exactly nowhere.

L Ellison
Wednesday, August 18, 2004

"L Ellison" is on crack. Everyone knows your only two options are Terradata or Excel.

Captain McFly
Wednesday, August 18, 2004

--Everyone knows your only two options are Terradata or Excel.

What do you mean?

Raju Patel
Wednesday, August 18, 2004

I hope UP...

It doesn't seem like the technology behind MSSQL scales real well though.

Certainly it doesn't scale as well as Oracle anyway... but the vast majority of folks don't need Oracle's power, or headache, or cost. (I think MSSQL devs are much easier to find/compensate)

I don't have tons of Oracle experience but I have a hunch that MSSQL is much more idiot proof.

I understand the point that MSSQL is somewhat in the middle of a noman's land. If you need major power, you go Oracle, and the little fledglings all stick to the very economical MYSQL.

It would surprise me if MYSQL ever outpaced MSSQL in corporate development use though. MSSQL provides people a scapegoat and another place to point a finger besides a mirror. That, and the corporate ideology of 'you get what you pay for'.

At any rate, I think it will be quite awhile before MS has to reinvent their DBMS.

I am Jack's bleeding colorectal ulcer
Wednesday, August 18, 2004

Oracle is indeed less idiot proof than MSSQL, but MUCH more scaleable.  MUCH MUCH MUCH.  And much more bulletproof and stable, especially on a *nix platform, but not too bad on Windows.

If you're going to shell out bucks for a database and you foresee having a very large dataset, Oracle is the way to go.  Make sure that if you go Oracle, though, that you get an Oracle guru to go with it.  It's not kindergarten like MSSQL is.

muppet
Wednesday, August 18, 2004

"Is MS SQL Server really a "Declining technology"?"

Did someone seriously say this? Quarter after quarter SQL Server has outpaced all of the other major database vendors in marketshare improvement, now coming in at a very #3 spot (from being virtually non-existent a few shot years ago). DB2 is the market leader, and has taken the crown at the expense of Oracle.

It's funny that all of the Oracle fanboys always bow to the god of Oracle, when the #1 database vendor is actually IBM with DB2.

Dennis Forbes
Wednesday, August 18, 2004

Nah Capt. McFly, "L Ellison" ain't on no crack.  He must be on sum sorta hallucinogenic, magick mushroom trip cuz everybody knows that Postgres and Clipper is the shiznit fo sho!

Smoove B
Wednesday, August 18, 2004

MSSQL is a market leader because my 6 year old could install and configure an MSSQL database.  It has little to do with reliability or scaleability.  In fact if those were the only metrics, I doubt you'd see much MSSQL out there at all.  It'd be all DB2 and Oracle.

muppet
Wednesday, August 18, 2004

"Oracle is indeed less idiot proof than MSSQL, but MUCH more scaleable.  MUCH MUCH MUCH. "

Really? Do you have some facts to back that up, or is it just one of "those things" that we should simply accept?

While the scalability argument is truly often a red herring (I know of one system that's the backend for a very large organization - a little SQL Server box running on a 4-way box), in the real-world SQL Server already scales to 64-CPU Itanium boxes (similar in performance to what people call "mainframes" these days), and of course you can expand your SAN (which is really the bottleneck on most systems) virtually infinitely. That's on one box, but if that isn't enough for you, you have been able to horizontally partition for virtually limitless scalability since 2000 using federations of servers.

In other words - whenever someone spouts about scalability and SQL Server, they have nothing to say and are falling back on a tried and true myth that hasn't held water for years.

Dennis Forbes
Wednesday, August 18, 2004

"MSSQL is a market leader because my 6 year old could install and configure an MSSQL database. "

Do you seriously think Oracle is difficult to setup and configure? This UNIX-versus-Windows argument is pretty weak when comparing Oracle versus SQL Server, given that Oracle is trivial to setup and configure, and PLSQL is hardly difficult compared to T-SQL. The "Elitez Skillz" defense just doesn't work in this case.

Dennis Forbes
Wednesday, August 18, 2004

Dennis,

You're right that I don't have tomes of research to back up my scalability claims.  I have only my own personal experience, which I'll believe over an article in a trade mag any day.  I've worked extensively with both MSSQL and Oracle, and Oracle simply stays up, gets the job done, and is a minimal hassle.

I'll admit that maintenance on an Oracle database is more time consuming than on a MSSQL database where you have pretty windows and flashy buttons, but you pay a fair price for stability and uptime.

I've never met an Oracle database I didn't like.  MSSQL, on the other hand, has caused me quite a few grey hairs and late nights.

muppet
Wednesday, August 18, 2004

"Oracle is trivial to setup and configure"

You mean like MSSQL where it's "Next, Next, Finish" ?

Not quite.

You're right, you can get an Oracle database up and running in a few minutes.  Getting a properly configured and optimized Oracle database humming along like clockwork, however, requires some of those l33t skillz0rz you're talking about.

MSSQL's optimization options are laughable beside Oracle's.

muppet
Wednesday, August 18, 2004

Muppet,

The fact that SQL Server is easy to install and administer doesn't necessarily mean it's a kiddie database system.

I've had the displeasure of working with Oracle for years. I will grant that Oracle will scale better than SQL, but not that much better.

On the other hand, Oracle is an absolute nightmare to work with. It's not easy, it's overly complicated even for things that should be simple.

Compare the cost of Oracle, and don't forget the DBA because you will certainly need one just to keep the blasted thing running, against the cost of SQL. In most cases, SQL will win if you look at through total cost by transactions.

And as far as the scaleability is concerned. Oracle is better, but again, it ain't that much better. It does support *nix which is an advantage, but there are very few cases where SQL Server can't handle the same load as Oracle with similiar hardware.

Whatever
Wednesday, August 18, 2004

"Lets keep in mind the SQL Server 2005 coming out in January."

Let's keep in mind Microsoft's projected/promised ship dates rarely are met.  If they say Q1, you add a quarter or two and you have an 80% chance of seeing it

Mike
Wednesday, August 18, 2004

Thank you for your eloquent defense of Oracle muppet.  For the rest of you MS SQL supporters "don't hate the player, hate the game"...

L Ellison
Wednesday, August 18, 2004

" 64-CPU Itanium boxes"

Can you honestly get one of these today if you wanted it?  What scares me most is that Oracle, DB2 and others have been 64 bit for a long time.  This is Microsoft's 64 bit 1.0.  I'd be a little leery of going to anything 64 bit from MS yet.

Mike
Wednesday, August 18, 2004

Verizon's billing system runs on SQL Server. I suspect Verizon has a little bit of data and a somewhat high transaction rate.

http://newscenter.verizon.com/proactive/newsroom/release.vtml?id=56629

SQL Server holds the #5 TPCC result:
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp

(and by the way, that's a five year old database engine against Oracle's brand new one)

Then, check out the price/performance results - oddly, Oracle seems completely absent.
http://www.tpc.org/tpcc/results/tpcc_price_perf_results.asp
So - if you happen to have as much data as, say, all the VA medical data (no, wait, that's on SQL)... okay, how about Barnes and Noble's website (nope, that's on SQL too)... maybe a major airline like JetBlue (sorry, SQL Server there)

Anyway, if you're on that scale, then do the price/performance analysis and draw your own conclusions. But be wary of the "my data is huger than anything on earth" trap - most business databases really aren't that big, nor do they need that kind of scalability. So then it's TCO and ease of development and maintenance. And SQL Server tends to win those analyses.

(and when you're choosing a database, don't forget to evaluate your requirements for analysis services and reporting, both of which are part of the SQL Server license)

Philo [Microsoft]

Philo
Wednesday, August 18, 2004

Microsoft eats babies.

muppet
Wednesday, August 18, 2004

"Let's keep in mind Microsoft's projected/promised ship dates rarely are met.  If they say Q1, you add a quarter or two and you have an 80% chance of seeing it"

Remember that SQL Server Yukon has already been pushed back several times (partly because they tied it, Visual Studio Whidbey, and the .NET Framework together, so each delays the other), and is currently at a very impressively feature complete beta 2. Some (very adventurous) firms are running systems off it right now. Given the critical importance of databases right now it may very well slip as they want to ensre that it is rock solid.

"Can you honestly get one of these today if you wanted it?  What scares me most is that Oracle, DB2 and others have been 64 bit for a long time.  This is Microsoft's 64 bit 1.0.  I'd be a little leery of going to anything 64 bit from MS yet."

Sure you can, though there are ___extremely___ few organizations that actually need it (it's like choosing your car based upon whether it can withstand a shell from a T72). Of course the big advantage of 64-bit is in address space, but SQL Server has support AWE (a sort of extended-memory) to address up to 64GB of RAM for years.

Dennis Forbes
Wednesday, August 18, 2004

If you want to talk TCO then let's talk about MySQL.  MySQL reduces the Total Cost of Ownership (TCO) of database software by:
· Reducing database licensing costs by over 90%
· Cutting systems downtime by 60%
· Lowering hardware expenditure by 70%
· Reducing administration, engineering and support costs by up to 50%

Even the talking head experts recognize MySQL as a serious entrant in the datgabase market.  In a Computerworld article, Charlie Garry from the Meta Group is confident that: "the future of the database market will be the standardization on MySQL."

Major organizations such as Cox Communications, NASA, Sabre Holdings and Yahoo! have improved database reliability, performance and TCO using MySQL. 

Check out the MySQL web site for more info.

MySQL Dewd
Wednesday, August 18, 2004

Muppet,

I'd like to hear your retort of the evidence that Philo stated. It kinds makes your argument seem...um..empty.

The Oracle vs MSSQL arguments always seem to be a lot of anecdotal and personal observations, not to mention an almost religious dogma from both sides.

But when you look at where MS SQL is being used, it shows that it's a proven RDBMS that is widely used in large corporations. I'm always a little suspect of TPC ratings since each side tends to do things that affect the rating in their favor, but overall, they are still a decent indicator.

That notwithstanding, I still view Oracle as ahead of MS in the database game. But I don't let my personal opinion blind me to the fact the MS SQL is a serious database system that is only slightly below Oracle in terms of performance.

But performance isn't the only factor. TCO is. And that's where Oracle is losing ground fast to MS. As Philo stated, not everyone needs 4,00 clustered 64 bit servers running on Unix. So when both MS and Oracle meet the performance requirements, MS can frequently win the cost requirement.

Schmuppet
Wednesday, August 18, 2004

+++But when you look at where MS SQL is being used, it shows that it's a proven RDBMS that is widely used in large corporations.+++

It shows that Microsoft has a powerful market presence and very capable salespeople.  Plenty of shops (I'm sure a lot of people here have dealt with this) have decision makers who are simply TERRIFIED of anything non-Microsoft.  If they're going to put money on the table, it's going to Redmond and a ubiquitous brand.  Oracle is regarded similiarly to Linux, in a lot of ways, by these folks.

I never said MSSQL isn't /capable/ of handling large databases and mission critical (within reason) systems, I just said it's not my DBMS of choice.  Were I given the choice of maintaining an MSSQL farm or an Oracle farm of servers, I'd pick Oracle every time because I'd spend the large part of my job at the coffee shop catching up on my reading.

muppet
Wednesday, August 18, 2004

In all fairness Philo the more relevant link for many large shops would be the non-clustered one http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=noncluster&version=5&currencyID=0

For those transaction frequencies the price of the MS SQL server is not significantly cheaper than other solutions (it is not even the cheapest). That might be a result of the different pricing strategies (MS bundles a lott of functionality into the base product that is delivered as extremely expensive add ons to the other DB's).

As a "light" user that is not a DB specialist I have been very happy with the robustness, ease of use and speed of MS SQL Server 2000. I expect MS to top these charts again with the release of 2005.

Just me (Sir to you)
Wednesday, August 18, 2004

"Check out the MySQL web site for more info"

until they run out of VC money, that is.

Just me (Sir to you)
Wednesday, August 18, 2004

"Plenty of shops (I'm sure a lot of people here have dealt with this) have decision makers who are simply TERRIFIED of anything non-Microsoft.  If they're going to put money on the table, it's going to Redmond and a ubiquitous brand.  Oracle is regarded similiarly to Linux, in a lot of ways, by these folks."

My experience has been exactly the opposite of yours: While senior management support and advocate Windows on the desktop, and as file servers or small needs, invariably they presume that they need a "mainframe" for the datacenter. It is an extremely tough sell advocating Windows boxes in central positions as there is a long standing, historically justified feeling that while Windows is good on the periphery, the data center should be run on big IBM or Sun boxes (indeed they need to be big, physically impressive boxes with lots of impressive blinking lights), with ridiculous expensive software from CA or Oracle on them. You have played on these exact fears in your messages above with the impression that while SQL Server or Windows is fine for little toy databases, when you grow up and take off the pampers it's time to upgrade to the big iron.

Dennis Forbes
Wednesday, August 18, 2004

+++invariably they presume that they need a "mainframe" for the datacenter.+++

I don't know what shops you've worked in, but during my past life in health insurance IT, the opposite was true.  Midrange solutions were shunned as overly expensive and Windows NT boxes ruled the day.  MSSQL was ubiquitous (and notoriously difficult to support, requiring an average of one DBA per half dozen boxes, on 3 shifts.)  The few Oracle boxes that managed to squeak by approval committees were a blessing.  The last company I worked for had 6 MSSQL DBAs for 30 servers and ONE Oracle DBA for 11 Oracle boxes.

muppet
Wednesday, August 18, 2004

MySQL Dewd,

At the moment MySQL is 5 - 10 years behind all other DBMS's in essential database features like referential integrity, constraints, triggers and stored procedures. The current version is essentially a file server, not a DBMS.

Because it doesn't have all those features, it is quicker than a real DBMS, but the downsize is that you have to write all the above mentioned features in your application, and that hits your TCO heavily and is usually not taken into account.

Anonymous by default
Wednesday, August 18, 2004

+++features like referential integrity+++

I've always felt that the database is the WRONG PLACE to enforce referential integrity.  This sort of logic SHOULD be at the application level.

Granted, there are complications with this when you have many applications all accessing the same database, but with correct process, it shouldn't be a problem.

You either code referential integrity or you code handlers for when referential integrity is violated, what's the difference?  The former, IMHO, gives you finer control.

muppet
Wednesday, August 18, 2004

"Granted, there are complications with this when you have many applications all accessing the same database, but with correct process, it shouldn't be a problem."

ROTFL! Please, muppet, stop it, it is starting to hurt.

Just me (Sir to you)
Wednesday, August 18, 2004

Anonymous by Default,

I think you are the one behind the times.  But thanks for your your well thought out post that was backed up interesting facts and figures. 

By the way according to the eWeek article “Server Databases Clash” that out “Of the five databases we tested, only Oracle9i and MySQL were able to run our Nile application as originally written for 8 hours without problems.”

What is so great about stored procedures anyway?  If you want to write object oriented code you put that in your code as well.  A database is there to store data for the application. 

You obviously don't know the difference between a file server and a relational database if you are equating MySQL to a file server.  I recommend that you read a good intro to relational database concepts book.

MySQL Dewd
Wednesday, August 18, 2004

"I'd spend the large part of my job at the coffee shop catching up on my reading. "

It seems all of muppets arguments center around him getting paid to do nothing but personal tasks on company time.

stuffet
Wednesday, August 18, 2004

"I've always felt that the database is the WRONG PLACE to enforce referential integrity.  This sort of logic SHOULD be at the application level."

You've got to be kidding!!!!!  I dare you to say that to someones face.

muppet don't know databases (among other things)
Wednesday, August 18, 2004

muppet,

Microsoft does not _eat_ babies. We merely need the blood for The Patching Rites.

Billy G.
Wednesday, August 18, 2004

Siebel, for example, is a company whose app handles all of its own referential integrity using their own homebrew GUID system.  Siebel is used by plenty of big name companies.  If I could be arsed to go look them up, I'd list some off.

muppet
Wednesday, August 18, 2004

Hi muppet,

I work on a Siebel datawarehouse project, and indeed there is no database integrity in Siebel. As a result the data that's in there is, to use the technical term, rubbish. You can store anything you like in Siebel, but making sense of the data that is stored in there in reports is a costly and complicated affair.

Anonymous by default
Wednesday, August 18, 2004

You can store anything you like in Siebel if you hack it up enough, yep.  If you work within the system, though, it generally works well.

I wrote customized reports using Perl against the Siebel 6 backend for years, and once you get used to the data model, it's actually a pretty neat system to play around with.

muppet
Wednesday, August 18, 2004

+++and indeed there is no database integrity in Siebel.+++

There is no /database enforced/, /referential/ integrity in Siebel.  There /is/ referential integrity enforced by the application.  Yes, you can break it if you really try, but then you've made your own bed.

muppet
Wednesday, August 18, 2004

So now you are saying that as long as Siebel is the only application on the DB, you will not have the problems resulting from multiple applications using the DB.

Great insight, muppet.

Just me (Sir to you)
Wednesday, August 18, 2004

Great strawman, Just me.

That is, of course, not at all what I said.  I said that with proper process and /competent developers/ (echo...), referential integrity is more properly handled in the application layer.  It is misplaced at the database layer.  I never once said that there should be only one application on the database.  I offered Siebel as an example of an application which handles its own data integrity.

Care to try again?

muppet
Wednesday, August 18, 2004

MySQL Dewd,

A database is there to store data for the applicationS. Plural.

That why you need integrity in the database, otherwise you keep copying it across all your applicationS.

I don't understand your comment about having object oriented code in stored procedures. I have never felt the need to put object oriented code in stored procedures, but I know they make control over the code that accesses the database far easier, because all the code is in one place instead of multiple applications.

Facts by the way:
MySQL has implemented referential integrity only relatively recently (the last 2 years?). I couldn't find exactly when, but I guess you can help me out on that one? SQL Server, to use one example, has had that since at least version 6.5 (the first version I worked with), which was released in 1996.

At the moment MySQL doesn't support check constraints, again something that has been around in SQL Server since 6.5.

Other DBMS's (Sybase, DB2, Oracle) might have implemented these features even earlier.

Anonymous by default
Wednesday, August 18, 2004

For clarification, I understand why referential integrity at the database level is necessary.  I just think that current implementations are a bandaid and not a final solution.

muppet
Wednesday, August 18, 2004

Muppet,

Referential integrity is not the only type of data integrity. for example, I have to deal with activities that end before they start in Siebel, maybe you can make sense of that, but I can't. Why isn't there a simple CHECK(end_date > start_date) on that table?

Anonymous by default
Wednesday, August 18, 2004

Anonymous -

Without knowing your specific issue (Siebel is a pretty big product these days), or the myriad ways in which your client/employer may have horsed with the system over time, I (or anyone) really can't begin to explain why you have an issue like that.  As such, it really doesn't enter into this argument.

muppet
Wednesday, August 18, 2004

Muppet,

no one application owns the DB.
people will screw up (unintentionally or otherwise)
process will not be followed (unintentionally or otherwise)

In most architectures the DB is where stuff meets. The constraints are there to make sure their is a minimum of integrity preserved is this brawl.
This authority should preferably not reside with one of the participating processes in the food fight that has no control over the other players.

"Hoping for the best" is not a good bett, and a guaranteed failiure on large projects.

Just me (Sir to you)
Wednesday, August 18, 2004

Application or ApplicationS it is all the same.  Poor database design is simply compounded across multiple applications.  I agree with you. 

MySQL has referential integrity, when it was implemented is immaterial. 

Check constraints should be handled in the application code.  If the user inputs something that violates the check constraint then you have to handle that error from database server so why not just handle it in the client application?  Won't this make your application more efficient?  If your answer is so that I don't have to do it in every single application that I write, my answer is refactor your objects and you won't have to. 

My comment about stored procedures is that you don't need them.  Put that code in your application.  This makes your application a pure object oriented application.  Although you do have a point that if you do use stored procedures you have all of your database access code in one place.  This is not a simple question to answer.  I personally happen to like to have everything in the code so I don't have to hunt around for stored procs.

You still have not given me any reason to spend more money on MS SQL Server. 

MySQL Dewd
Wednesday, August 18, 2004


Well, if everyone agreed to play nice and enforce referential integrity in their applications, then life would be grand.

Unfortunately, that isn't reality.

Dozens of teams are quite likely to be coding applications against the same database. Sometimes (gasp!) a programmer forgets about handling referential integrity in their app.

Boom. Now everyone using the database is hosed.

No, a much better solution and one that is commonly used, is to put referential integrity into the database first and foremost. Then, the applications also enforce it.  So you have the applications acting as the first line of defense. In the event of a programmer failing to do that, the database will catch the error.

Pretty simple (and pragmatic) approach. This is why having a database that supports referential integrity is important.

Whatever
Wednesday, August 18, 2004

MySQL Dewd,

The problem is not "every single application that _you_ write". The problem is every single application that anyone will ever write against the database.  So you can either put in a check constraint, which is 100% water tight, or you have to implement all kinds of source code review to make sure that no one ever accesses the database outside your objects. And people will do that, intentionally or not, because they get shoved onto a project where they don't know all the ins and outs of the application code.

I hope you don't have the wrong idea that MySQL is actually free. It might be open source, but it is created by a company, and there is a cost to the licenses for commercial use (not even talking about support). In contrast to that, Microsoft actually ships a limited version of SQL Server (MSDE) that is really free for commercial use.

Anonymous by default
Wednesday, August 18, 2004

I did not say the MySQL was free, just that MS SQL Server was more money.  Although, the source code is free to tamper with if I so desire once I have paid the licensing fee.  The MDSE is not free since you have to have a Windows licensed OS to run it on, which are not free.  Is the MSDE as fully featured as MS SQL Server?  If it is then why would anyone develop on MS SQL Server (just curious not an attack)? 

Also, I think the lack of triggers in MySQL is a bigger issue than the check constraints.  MySQL is definitely not the answer to all of your database needs, but it does satisfy the needs of some big organizations which was part of Philo's argument for MS SQL server.

PS.  What do you think of  Firebird?

MySQL Dewd
Wednesday, August 18, 2004

"but SQL Server has support AWE (a sort of extended-memory) to address up to 64GB of RAM for years."

Sure their is the intel PAE kludge and AWE, but in NO WAY is it comparable to directly addressable ram like you'd have on a true 64 bit platform.  MS is 1.0 at best on 64 bit.

It always seems like on paper the Microsoft products analyze better than competitors, but in actual use, the Microsoft products tend to be less reliable, less scalable and more of a support headache. 

TPC results are somewhat a joke.  I do believe Microsoft does a better job of designing it's products to do well at the TPC-C event.  The do quite well in the price/performance because intel hardware is dirt cheap compared to Unix hardware.  If you look for sheer non-clustered performance SQL doesn't do as well, and if you look at TPC-H SQL Server bows out while the others keep going to larger datasets.  SQL Server is improving.

The thing I keep in mind is that a lot of shops run TPC-C and TPC-H types of things out of the same database at the same time.  If this is true for you, Oracle will be better because of readers and writers not blocking one another.

Mike
Wednesday, August 18, 2004

Just Me -

Nowhere did I claim "hoping for the best" was a good approach.  I said that referential integrity belongs in the application layer (perhaps ideally through some shared objects (web services?) or libraries), and not the database layer.  Whether this works out in practice with current solutions is an entirely seperate issue.

muppet
Wednesday, August 18, 2004

Boy, so many comments in few hours!!! ;-)

So guys can we conclude that MS SQL Server is certainly NOT "Declining Technology". It may have some catching up to do when compared to Oracle but it dose have its own market.

Raju Patel
Wednesday, August 18, 2004

"The do quite well in the price/performance because intel hardware is dirt cheap compared to Unix hardware"

What is "UNIX hardware"? In any case virtually all of the DB2 and Oracle price/performance results were on Intel hardware (as opposed to the mythical UNIX hardware). There goes your first point.

"If you look for sheer non-clustered performance SQL doesn't do as well"

Yeah, 5th highest non-clustered performance really blows (on a $5 million dollar of, err, "UNIX" hardware), right? There goes your second point. Keep in mind that this was submitted, and held the top rank, before the current top 4. I expect Microsoft to make some big numbers leading up to the SQL Server 2005 launch.

"and if you look at TPC-H SQL Server bows out while the others keep going to larger datasets"

They _all_ start voluntarily "bowing out" - these tests are bloody expensive to run, and there is a law of diminishing returns trying to submit for absurdly massive databases. This point is just inane.

Dennis Forbes
Wednesday, August 18, 2004

" In any case virtually all of the DB2 and Oracle price/performance results were on Intel hardware (as opposed to the mythical UNIX hardware)."

Oh, really?

http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=noncluster

I guess Unix hardware isn't mythical.

"Yeah, 5th highest non-clustered performance really blows (on a $5 million dollar of, err, "UNIX" hardware), right? There goes your second point. Keep in mind that this was submitted, and held the top rank, before the current top 4. I expect Microsoft to make some big numbers leading up to the SQL Server 2005 launch."

Look in the number 4 spot on the link you're citing - that would be Unix.

Mike
Wednesday, August 18, 2004

How could MS SQL Server be a declining technology with all of tht sexy Microsoft marketing muscle behind it?

Just wondering
Wednesday, August 18, 2004

"Oh, really?"

Yeah, really - The follows is price/performance and is filled by Intel hardware. You were the one who mentioned price/performance.

"I guess Unix hardware isn't mythical."

UNIX is an operating system standard, and runs on all sorts of hardware, including Intel. Windows, the platform of SQL Server, ran primarily on Intel (they did explorative tests with other platforms, but found that when the software platform was common people just bought x86), but now runs on x86, x86-64, and IA64. IA64 has machines that are as big as the biggest "UNIX" machine.

"Look in the number 4 spot on the link you're citing - that would be Unix."

Actually on the link you gave, the #4 non-clustered (my mistake that I called SQL #5) is SQL Server running on Windows, albeit running on a 64-processor IA64 machine. What is your point again?

Dennis Forbes
Wednesday, August 18, 2004

Number 1 and 3 are not SQL Server and are lower cost / transaction. 

Mike
Wednesday, August 18, 2004

"UNIX is an operating system standard, and runs on all sorts of hardware, including Intel."

Sorry.  I should have just said non-intel or intel emulating hardware (AMD) of a 64 bit implementation.  Would that have helped?  In other words a platform that doesn't run Windows.

Mike
Wednesday, August 18, 2004

"Number 1 and 3 are not SQL Server and are lower cost / transaction. "

Are you just trying to play with my head here? What chart are you looking at? In nonclustered price/performance 1 & 2 aren't SQL Server....but they're running on standard Intel hardware.

"I should have just said non-intel or intel emulating hardware (AMD) of a 64 bit implementation.  Would that have helped?  In other words a platform that doesn't run Windows."

Right, like the IA64 (Itanium) 64 processor machine in the #4 spot on the non-clustered gross performance TPC-C, running Windows 2003 and SQL Server 2000.

Dennis Forbes
Wednesday, August 18, 2004

As an aside, I should note that of course the Itanium is an Intel chip (codesigned with HP), but the IA64 instruction set shares nothing in common with x86 - it's a completely different architecture. The design of the HP Superdome shares very little in common with PCs.

Dennis Forbes
Wednesday, August 18, 2004

This link, Dennis
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=noncluster

The ones I'm speaking of are PSeries, which is not an Intel architechture.

Mike
Wednesday, August 18, 2004

MySQL Dewd,

MSDE is basically the same engine as a full blown SQL Server. It doesn't come the graphical management tools that SQL Server comes with normally, and it doesn't support some high-end features like clustering, OLAP etc. It does have backup/restore though. It has 2 main limitations: a 2 GB limit on database size and a performance throttle with kicks in around 20 concurrent users. It is intended to be used as an embedded database for desktop/workgroup applications.

You are right that you still have to pay for Windows, but it's a database for an application that you sell on to customers, and they presumably  have already paid for the Windows license.

I think that regarding triggers you are under the with OO programmers common misconception that triggers are a kind of events. They are not, they are a type of (complex) constraints, the same as primary keys, check constraints and even datatypes. They _must_ succeed otherwise the transaction that fired them is rolled back. (Ok, that's the implementation in SQL Server, I assume other RDBMS's might have a somewhat looser implementation. All I say further in this post is how things work in SQL Server).

Now, the thing with a trigger being able to roll back the transaction, is that all the locks on the database table that the original update/insert/delete took out must be held until the trigger completes, and this affects concurrency.

Anonymous by default
Wednesday, August 18, 2004

Sorry Mike we've gotten wires crossed as this has jumped between performance, where indeed most of the machines are not machines that Windows runs on (not that it really matters - #4 proves that if you want extremely high performance with SQL Server, and you're willing to pay for it, you can have it), and price/performance where every single machine (running Oracle, DB2, or SQL Server) is an Intel commodity style box.

Dennis Forbes
Wednesday, August 18, 2004

<quote>
performance throttle with kicks in around 20 concurrent users.
</quote>

Actually, it kicks in with five concurrent *queries*.

Mind you the new version of MSDE ( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsse/html/sseoverview.asp ) will be completely different in that regard.

Anonymous
Wednesday, August 18, 2004

First of all, I'm a SQL Server DBA, so I'll lay that out first. Second, I spent nearly a year managing the production database team at a Fortune 1000 company, running Oracle, SQL, and DB2.

All three are trivial to install for someone that is qualified or has experience doing so. I wouldn't assign my DB2 people to work on SQL Server or vice versa because they couldn't do it. All three can be managed well or not managed well, regardless of the DBA skill level. MSSQL may be easier to install than the others, but it doesn't mean it runs better.

All three RDBMSs are great systems. There is no better one. They excel in different areas and somewhat depending on your needs and very much depending on your people's skills, you choose the one that makes sense.

That being said, I've seen enterprise applications with thousands of concurrent users run on DB2 and I'd put my SQL Server up against them any day. Most of the end user performance comes from a well written application, not a write once suck on all platforms one.

An example: I ran a 4x4 SQL Server with a data warehouse supporting real time queries from about a hundred users for BI work and a 600GB database for a couple years on SQL 2000. It smoked and was almost never down. I managed a 300GB warehouse on DB2 that had lots of issues and required downtime to respin cubes. Is DB2 worse than SQL? No the app developers were worse. ROI was much better with SQL as was performance, user sat, any other measure you want.

As far as MySQL. I haven't played with it in about 3 years. At that time it was 10 years behind SQL Server. I hear it's changed lots, and implemented lots of featues. If it's 5 years behind the big 3, it will catch them in < 3 years. Easier to cpy and move up than innovate. Plus the model supports it better.

I'd say Oracle is a declining technology. If you're a Windows shop, you probably go with SQL Server. Easy to develop against, relatively low cost,etc. Developing against MySQL isn't as easy (yet). If you use Unix, you don't consider SQLSErver, so your choice that you look at to save money is MySQL. Oracle will lose market share to MySQL.

DB2 is growing becuase IBM plays games and is cutting serious deals everywhere for market share. They recognize this and I wouldn't be surprised to see DB2 merge with MySQL just as I suspect AIX will merge with Linux.

Keep in mind there's a lot more to it than the software cost. Skills, training, development add up to way more than the software cost.

As far as RI not in the database. Doesn't even deserve a comment. It's a "slashdot" comment.

Steve Jones
Wednesday, August 18, 2004

+++I'd say Oracle is a declining technology. If you're a Windows shop, you probably go with SQL Server. Easy to develop against, relatively low cost,etc.+++

You first state that Oracle, MSSQL, and DB2 are roughly equal, then you say that Oracle is a declining technology because MSSQL is easier to develop against?  How do you figure that?  Have you got examples of the ease of development against MSSQL vs Oracle?

Theoretical arguments are "slashdot" comments undeserving of remark?

Zero.  Credibility.  Mr Jones.

muppet
Wednesday, August 18, 2004

"I've always felt that the database is the WRONG PLACE to enforce referential integrity.  This sort of logic SHOULD be at the application level."

Please, please, just come shoot me instead.

At least now I know where to look. In a scenario where your data is touched by multiple apps it would be quite a pain to hunt down the app that has the logistics problem.

Wouldn't that also mean that if you decided to change data structures (indexes/keys) you'd also get to change code and recompile/re-deploy!?!? Multiple applications???

Were you shooting for some sort of job security on that one?

I am Jack's intense fear
Thursday, August 19, 2004

It's not a theoretical arguement, it's a waste of time. Developing any group of applications against a database will quickly show you that enforcing RI in an app doesn't work. Might be an "idea" but it's not an effective practice.

I stated Oracle was declining for the reasons stated. Regardless of how "good" a product it is, my guess is that it will decline inuse.

Ask anyone to "whip" up a prototype for some app. In general it is easier to build against MSSQL. You might do a better job with Oracle, but the average person I have to hire or work with does a better job with SQL Server, which is heavily integrated into Windows.

Steve JOnes
Thursday, August 19, 2004

I think muppet's a troll

Jon
Thursday, August 19, 2004

+++Ask anyone to "whip" up a prototype for some app. In general it is easier to build against MSSQL. You might do a better job with Oracle, but the average person I have to hire or work with does a better job with SQL Server, which is heavily integrated into Windows.+++

So your justification for your argument is another lump of subjective falderal?  I see.

muppet
Thursday, August 19, 2004

Actually, I happen to agree with that generalization, and I'd be interested to meet someone who honestly thinks it's easier to prototype with non-MS tools. I've met a few Java and Powerbuilder types who used VB6 or Access for prototyping all the time.

I don't think "ease of use" has *ever* been an area that anyone accused MS of being behind the power curve on.

Another interesting generalization, which is probably falling apart post-DotBomb: In general, the lines between developer and DBA seem much more defined in Oracle land than in SQLville.

Philo [Microsoft]

Philo
Thursday, August 19, 2004

+++Another interesting generalization, which is probably falling apart post-DotBomb: In general, the lines between developer and DBA seem much more defined in Oracle land than in SQLville.+++

This is NOT an advantage of SQL Server.

muppet
Thursday, August 19, 2004

and Philo, now you have "met" someone who believes it far, FAR easier to prototype with non-MS tools.

And you don't feel dirty, afterwards.

muppet
Thursday, August 19, 2004

SQL Server is up like superman. SQL Server doesn't scale? I've got a 2TB database that would beg to differ. Another SQL Server friend of mine is also dealing with a "SQL Server doesn't scale issue" with 899GB in ONE TABLE. The problem is it is still running well enough for them not to change it. I've built systems that scaled out on to multiple servers and have had the good fortune to play with HP Superdome's and ES7000 servers running SQL Server. In all aspects, SQL Server fits 99% of most bills. It scales up, it scales out. It also has the same issues going into the VLDB space as the rest of the boys, when it gets that big you have to manage it with some amount of intelligence I/O being the big killer. I find people bag on SQL Server when a) they use it and have no real clue how to use the feature set or b) they are completely sold on another platform. At least the first type of people can be educated. I also acknowledge that SQL 2000 is missing things Oracle has had for quite a while, all of that changes with SQL 2005. Bash release dates all you want, I'm running beta 2 right now and have found nothing it can't do that Oracle can. With all that said I'm also a huge fan of MySQL I have deployed fairly large data sets 400GB on it using hardware that Oracle or MS SQL wouldn't run on worth a damn. For those who keep talking the "MySQL doesn't have the features" Crap take a look folks, the latest alpha MySQL 5 has it all, and more. It can do things that MS SQL can't with some data types and rad indexing schemes. You don't hear MS sweating Oracle or DB2 in their market space, its MySQL. Not to mention I'm a MySQL sinner, I run MySQL on Windows quite a bit.

I'll swear by MS SQL Sever, it pays the bills. I'll hedge my bets with MySQL, it is growing like a hungry virus.

Wes Brown
Thursday, August 19, 2004

Muppet, you are a troll and have proven to have no integrity on this forum.  Nothing you say can be believed.

Jj
Thursday, August 19, 2004

Muppet by name...

I Can't believe its not butter.
Friday, August 20, 2004

For every business choice there is an appropriate RDBMS to drive it. MS SQL Server certainly rolls out quickly, but is not as powerful yet as Oracle or DB2 (see the ANSI SQL standards where SQL Server has not yet met the 1999 standards).  Some of these standards are on SQL statement capabilities, specific complex joins for example.  Other standards center on DBMS structure, like support for field level triggers as opposed to a table level trigger. 

But each analyst must decide what is needed by the DBMS prior to making the decision.

We can argue about scalability all day, as most people with experience in one platform view scalability from a different perspective from someone who has experience on an entirely different platform.  Mainframe analysts will say scaling isn't adding more servers...that's just adding points of failure.  Windows analysts will tell you it makes no difference if you grow up or out...as long as you grow...

MS has poured it bank roll and bet big on MS SQL Server, so I would say it is 2 releases away from being an enterprise class database engine.

Jeff
Friday, August 20, 2004

OH, and one more thing...there are 3 versions of IBM's DB2 product and all 3 meet different levels of the SQL Standards.  Interestingly when comparing standards IBM will use the base code that comes closest but doesn't run in the UNIX or Intel space.  But when looking at TCC (total cost of computing) IBM will switch gears and use the Open system edition which is lower in cost and functionality.

If you look long enough you can find a statistic to support any claim you make.  That's why your business needs should drive the RDBMS decision, and not who's cool today.

Jeff
Friday, August 20, 2004

Look,

I don't pretend to be a DBA Extrordianaire or even a SQL Server fan, but in the realm of having lots of work to do that requires more and more reliance on data stores and warehousing.

I'm sure there is more than enough business to be done to keep Microsoft & Oracle busy through the next millenium.  I remember when there used to be threads like this about mainframes and they're still used broadly as well.  SQL Server is up, for good, because businesses build their business on it, plain and simple.

Rodney Brooks
Friday, August 20, 2004

I agree, the majority of what I see here is a rant based on perceived superiority. There are too many factors to consider to accurately say MSSQL is better than Oracle, or It's dying off. MSSQL was never designed to take the high end market, so of course it isn't the top player. These products all work well in the arena they were designed to operate in. As for the minor threads I see here :

Regardless of which platform:

1) If your architecture used is flawed neither the app or the db technology is going to be percieved to work well by a very large population.

2) If your developers are idiots the it doesn't matter how well the Db server is configured, or where the integrity logic is placed.

3)  If your DBA is mentally or procedurally challenged, Neither architecture nor stellar programming will be noticed, in light of the other issues.

4) If the hardware used to support the above is not scaled to the proper level, All of the above will appear to stink.

The simple unvarnished truth, is that the "best" answer is simply using the best mix of technical talent with a platform that will be best utilized by the team of professionals supporting it.  Let's not lose sight that we're all here to build a tool to make something happen, and the real trick is to build a tool that works for the given situation. Not all situations.

My favorite analogy (which is not perfect) is :
"You don't use a chevette to haul gravel, and you don't take the chevette to the Ford dealership to get it repaired "

Simplistic, Pragmatic, and still working after 20 years of IT...

Willie
Friday, August 20, 2004

We looked at standardizing on an enterprise database platform for our university in the Summer of '02.  Looked at SQL Server, Oracle, DB2, and MySQL.  Choose SQL Server for the following reasons:

Initial cost.

Scales way beyond our needs, so who cares what the outer limits of scalability might be.

Will be around in ten years.  Not sure you can say the same for MySQL.

Ralative ease of use for developers and semi-developer.  We recognized that whatever platform we chose we would need to make sure we had trained DBAs in the back room.  But SQL Server is easier for the folks who need to be database owners, for folks who need to consume data tables via web pages, and integrates easily with Excel or Access front ends.  An enterprise database system is most valuable if it empowers data users all over campus.  SQL Server does this without needing to purchase any additional software beyond the MS-Office suite we already deploy.

Lots of support from vendors of other systems.  We now have a fundraising system, an event support system, a campus safety, a facilties management and an HR recruiting/hiring system that all run on SQL Server out of the box.  Furthermore, we run a campus administration system that runs on a non-standard database, UniData.  That vendor has now decided they will release there next version on UniData and SQL Server.  They previously tried porting to Oracle but found their customers unwilling to move to that significantly more expensive solution.

We have seen more and more vendors porting to SQL Server.  This is one very good reason for a business to go with SQL Server.  If you only want to staff to support one enterprise database system then you want to look first at whether you will be able to buy affordable and satisfactory systems using that same platform which meet your various business requirements.  That requirement tends to leave out MySQL.  And at least when we looked, solutions build on Oracle tended to be very expensive compared with similarly capable solutions build on SQL Server.

So even if SQL Server is second rate in some pure purformance/database theory sense it seems to be in the VHS position vs. Oracles Betamax.

Bob
Friday, August 20, 2004

Apparently none of you use data warehousing as Analysis Services that come free with SQL Server is one of the easiest DW packages out there. I can create cubes in 5 minutes try doing that in MYSQL or Oracle or Sybase

brian
Friday, August 20, 2004

We looked at standardizing on an enterprise database platform - Bob

While one size may not fit all, I do appreciate it when common sense prevails for any given situation.

Gary

Gary Andrews
Friday, August 20, 2004

Hmm... RI...

It is possible in Siebel, SAP, PeopleSoft, etc., to go in as a DBA and manipulate the data in the database outside of the application's structure. This is generally a Bad Thing.

Even using a modicum of Referential Integrity, with triggers, etc., for audit logging, etc., is likely to make Risk Management, Internal Auditing, etc., slightly happier.

So Siebel, SAP, Documentum, etc., manage their metadata essentially outside of the database per se? Well, good for them! But this means they don't have to tweak it for a myriad of database systems, either. THIS is the real reason why they do it. They do not want to have to check for differences between Oracle 8.1.6 on Solaris or SQL Server 2000 on Win2000 Data Center, so they just do their own application-level (or middle-tier) referential integrity.

Having needed to check a Documentum-based application for whether it was correctly storing documents, I did figure out ultimately how it was storing the physical document name map in the file system with the logical name in the database, just to make sure that the J2EE-based layers above that were interacting with Documentum correctly.

At the very least, an application can have an "interface" specification, which defines the functions and return values. So it should not matter whether a middleware layer manages this, whether it is implemented fully in the application, or implemented mostly using database features (i.e., stored procedures, triggers, RI)...

Programmers like to abstract the database as merely an abstract data store container. DBAs abstract the application as merely one presentation layer of many...

the "purely object-oriented" fascists who abstract the database merely to being a high-speed data persistence engine tend to take things a little too far, imho.

corey lawson
Friday, August 20, 2004

For those of us who have a mixed Oracle and SQL environment, Oracle Designer and the Oracle job agent are the declining technologies that pushed us in the SQL direction.  Maybe all of this has been fixed by being worked into 9i/10g Oracle Enterprise Mgr (or other Oracle products)?  For DBA tasks, Oracle seems to be "script city" where SQL is virtually scriptless. 

jb
Monday, August 23, 2004

I have been a DBA for both IBM DB2 for S/390 and Sql Server for some years now. Although I consider DB2 to be more advanced in many topics than Sql Server (and I have always liked the static Sql option), Sql Server does a good job for most applications. I agree with the ones who commented that every company should choose the platform which is right for it, which means taking into consideration a lot of issues, such as hardware platforms, initial cost, existing skills, performance, availibility, existing dbms, tco, scalability needs, portability, etc. For many organizations, Sql Server is the right choice, for others it would be DB2, Oracle, Sybase, MySql - or maybe a niche player.
I don't think Sql Server is declining, although I do have a problem with Microsoft's policies. I think Sql Server could have done a huge leap if it tried to compete outside the Windows platform, I don't like the bundling of SqlServer with other Microsoft products (like Shared Point Server), and I certainly don't like their releasing policy - one major release every 2-5 years seems like lagging behind...
Having said that, I still think Sql Server is up and running.

DB Geek
Tuesday, August 24, 2004

*  Recent Topics

*  Fog Creek Home