Most DB vendors are playing catchup with each other as each introduces new features. There are great features in Oracle, MySQL that I'd love to see in MSSQL (looks like 2008 has many of them).
I was sitting in an Oracle Admin course a little over a year ago. The lecturer was preaching about how much better Oracle was (than MSSQL) He was using examples of great new features, being the only MSSQL DBA on the course I prefered not to start an Oracle vs MS argument, but had to quietly chuckle to myself as all his examples were functionality that had already been in MSSQL for years.
Having read a little about SQL 2008 I think it's probably the closest MSSQL has come to matching all of Oracles "would be nice to have" features.
Personally I think the few features in MySQL that MSSQL doesn't have hardly qualify it as better. We've managed without them for years and found alternative solutions. The cost on the box is hardly what makes a database expensive. The long term development and management costs are what makes the big difference. For me MS wins on this one!

MySQL's only reason for popularity was marketing and it was free.
(LAMP)

Personally I also like the free GUI tools MySQL Administrator and MySQL Query Browser. Query Browser creates a select-query when you double-click a table, allows you to update data in the result set via a grid, lets you jump to the last record, lets you search in the result set, has a pane with an overview of all supported functions and variables and jumps to the right section in the manual when you double click it (something I really miss in Query Analyzer or management studio; there is no "hard-link" to BOL).

@Adam
>Some people get way, way, way too fixated on certain things and miss the big picture altogether.
Yes indeed. Of course just what 'you' have in mind by 'the big picture' is an open question:)
@Paul
>database folks do tend to know only thier favorite product and hear only disinformation about the others.
Yes indeed. Also an out for being intellectually and professionally lazy:)
Also I would like to draw attention to the difference between the nah nanny fofo game of feature-tag versus real criticism. If your not aware of the later not to worry, like porn you will recognize it when you read it:)

Aaron,
Yes there are "many" ways to accomplish this: "query dependecies", "invalidating triggers" (your method), stored procedures with decaying policies …. etc
Something "built-in" in which you can control the cache expiration on a "per-query" basis is extremelly useful in my current place.

See, I don't know if I agree completely with your comments, Geoff.  Several of the things Microsoft is adding seem to me to be quite unique, for example most of the enhancements to the BI side, and then things like dynamic management framework.  Other things, like MERGE, are not just about "keeping up with" some of the other platforms, but also about conforming more to the standard…

Yes, Frans, that seems like a good one.  (Though, I wonder if it's really all that much easier to implement than any of the numerous workarounds we have for that missing functionality?  Same question for row subqueries.)

noeld and Paul, I have implemented similar functionality that involves something as simple as a table with two columns: entity/table/view/etc. and last updated.  The app calls a stored procedure that checks the last updated value for whatever it is interested in.  If it is greater than the value the app has stored, it reloads the data, otherwise it just uses what it loaded last time.  The value, of course, is kept current with a very simple trigger.  While it is manual and not just a knob, it's quite simple to implement, all things considered.  In addition, it is very easy to tweak the trigger for your own purposes, e.g. for certain types of data it may not be important to refresh the cache when column A has changed, but column B and C absolutely need to be current.  Also, I would suspect that a simple built-in SQL Server implementation would invalidate the cache whenever an UPDATE statement fired, regardless of whether or not the relevant data actually changed.  Using my approach, I can write the trigger as I see fit and not have to worry about or learn little implementation details that someone else decided.

Dunno about MySQL, but the Oracle flashback data archive was brought to my attention just yesterday:
http://www.oracle.com/technology/products/database/oracle11g/pdf/flashback-data-archive-whitepaper.pdf
I'm not aware of a SQL Server equivalent.  I hope you guys can prove me wrong, because this looks really useful!

"Query RESULT cache" this in my opinion is a *BIG* deal for "certain" apps MySQL has it  not MS SQL Server.

Peter: You can write your own RegEx function in three or four lines of C# code (depending on which RegEx feature you want to use) and expose it via SQLCLR.

In an instructor's lounge a few years ago, a couple Oracle instructors were bashing SQL Server claiming that SQL Server was limited to foreign keys nesting limit of 32, and that it couldn't really handle database of more than a few Gbs.
So yes, Adam, I agree with you, database folks do tend to know only thier favorite product and hear only disinformation about the others.
When I do meet a DBA who is competent on multi-platforms (I worked with one last year who knew SQL Server, Oracle, DB2 and Informix) I'm impressed and envious.

Hey, I was born on Feb. 30th, 1974.  🙂
I was unaware of the natural join syntax.  After briefly skimming the doc, it seems like initially it was just shorthand to prevent naming each column twice in the ON portion… but now they are actually smart about it and conform to the standard by eliminating the redundant columns.  I am not sure if I would want that precise functionality in SQL Server, not only because I do not use SELECT * (so it would not be saving me any columns in my return list anyway), but also because it does not seem well-defined which "j" is returned.  I assume it would be the left-most table?  What if I had a right outer join?