Slashdot Mirror
New SQL Server Release Slips to 2005
Strudelkugel writes "CRN reports SQL Server 'Yukon' will slip to 2005, complicating plans for ISVs and creating opportunities for OSS and other competitors."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
--Mike--
i think you'll find PostgreSQL is also pretty good value for money!
"Early adoption of Yukon in enterprises was quite strong due to the functions and features [..]"
How can you talk about functions and features of software that has not yet been released? How can companies "early adopt" vaporware?
Yes, they can order in advance, but to me "adoption" means running something as a part of your business. Not "planning to maybe use it once you get it and if it turns out to be as good as you was promised it would be".
Being bitter is drinking poison and hoping someone else will die
It is really funny the level of fervor behind Mysql. So funny it makes you wonder if the zealots have ever used anything other to any real extent.
The company I work for software's backend can go Mysql, Postgres, Mssql, Db2, or Oracle.
For massivce connections, queries, reporting, reliability it is in this order.
1. Mssql, DB2, Oracle, all pretty much equal.
2, Postegres, tricky but holds its own.
3. Mysql, will work in the low end, forget reporting, forget huge db hits.
I like Mysql. But Mssql 7.0 hands its ass to it.
What happens is some company will be our product. Hand it over to some 25 year old self proclaimed web genius to install. Conversation is as follows.
1. "Can I have the Source?" No, it is closed, long discussion about how we suck cause our product isn't open source.
2. "Ewwww, Java, it sucks, you should rewrite in PHP" I explain it has been continually developed since 96, no way to stop the engine and write in PHP.
4."I decided to save the company some money and install Mysql" We say ok, explain issues, put them in an email and fax(CYA principle). I then advise to run Postegre, that it is more robust, and is FREE as well.
No one lists. Junior installs on Mysql, everything runs fine, site gets huge amount of traffic, database gets quirky. Management starts running huge queries on database reporting tool. Database is very slow to respond, then in a few weeks keels over.
We get called. Tech is yelling, my guys are smirking(but still polite on phone) Management, myself, and tech gets on conference. Tech starts berating me. Management starts berating me. I pull out magic email and fax with all my system recquirements, suggestions for optimal use. Hey, guess what I was write. Wait a minute, shouldn't I know best since I work for the company that writes and support the product?
Three times a week this happens with Mysql. We have 14000 customers and I swear 50 percent have some guy that thinks he knows best.... knows our product better, knows computers better...
This is a great example of where our community needs to clean up its act. And I thought I would never say that.
Mysql is good for what it is, but there are many things it is not. Learn this.
Puto
The Revolution Will Not Be Televised
Firebird
Postgresql
Maxdb
They all beat MS-SQL consistantly, and postgresql is coming close to toppling oracle!
Mysql isn't the only open source database in the world. It is popular because 90% of users DON'T need all the flashy features.
CNET News reported five days ago on the 10th that both Yukon and Whidbey would be delayed and their final names. They need that time if they are going to clean up the shit HTML and JS outputed by VS. Not that they will, that would allow people to use Firefox.
Microsoft delays database, tools deliveryPhillip
Isn't Slashdot run on MySQL?
This is a good example of how far behind MySQL really is. I don't want to degrade the db; I have used it on several PHP/MySQL driven sites. However, Oracle, IBM, Microsoft, Sybase and others have had transactions for many years. I have only been developing professionally for about 7 years (circa 97), but I started out on SQL Server 6.5 which had full support for transactions. SQL Server 7.0 had support (via MTS) for distrubuted transactions (across multiple databases). If MS had this back in 1997, you know Oracle had it before then.
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
I agree, you can bash Microsoft all you want just because that's who they are, but don't bring up MySQL as an alternative to any real database, be it oracle, postgres or mssql.
You can take a look at Sybase ASE which runs on Linux, Windows, Solaris, etc.. As I'm sure you are aware Sybase wrote the original SQL Server and licensed it to Microsoft. When they split (around version 6.5 I think) Microsoft took the SQL Server name.
In any rate, Sybase ASE uses the T-SQL dialect and also has many of the same stored procedures for system administration.
Thanks,
--
Matt
slated to be released until the last quarter this year. 2005 "sounds bad", but it's only a few months.
Because stored procedures are kept on the DB side and can be optimised and cached by the DB, and also it means that less stuff needs to be sent from DB machines to other machines - all the processing is done in the DB and just the final results sent out.
Jon Erikson, IT guru
JohnFluxx wrote:
> Could you tell me why you would use stored procedures?
> It just seems better to have another layer that handles that logic, seperate from the database. That way you can change databases easily.
Sure - that's a good approach - especially if you've got a product that you want to support on N databases. However, it's pretty difficult to implement a complex application with completely generic sql anyway. So, when working with complex apps - the use of simple stored procs can actually simplify porting.
But in a more typical situation -when you're developing an application for a single database, and your primary concern might be that the client may want to switch databases in the future (but it will still only run on one database product), *then* the case for stored procedures is much stronger.
Typically I'll implement stored procedures for four reasons:
#1 Parallel Development: stored procedures allow the database & application teams to develop in parallel. For example: as soon as the object model is created, the database team can approve it and commit to delivering stored procs that map to that spec. The same day the developers start writing code. While the developers are writing this code the dbas figure out the physical model and then map that to the procs. I've used this technique to often cut 3-5 weeks off project time-lines.
#2 Physical Model Adaptability: often in complex applications performance dynamics can change over time, requiring that the data model be tuned to handle new situations. With an abstraction layer of stored procedures the dbas are freed to easily make these modeling changes without significant interaction with the developers. This works better for some organizational structures, and even when the dba & programmer are on the same team, it still allows the one person with the greatest sql skills to perform the entire change - and does not require a team to perform impact analysis on both java and the database.
#3 Database Performance: again, in complex or performance-intensive applications, some queries can be extremely complex. However, the folks who are typically the best at tuning the queries are the dbas, not the developers. For example, I sometimes have to split a query into separate steps, with creation of a cartesian-product table as a first step, then joining against a few other tables as next steps, then pulling everything together in a 4-6th step. I can encapsulate that query behind the scenes and offer a relatively simple-looking table to the developers to work with. The programmer's best attempt at tuning their query took 2 minutes, and I got it down to 2 seconds - but there's no way that they can maintain the query I created. Other performance-benefits occur when the dba partitions data across a cluster, and includes logic to determine which node to run part of the query upon. This shouldn't be in the application layer - since it's very database system dependent.
#4 Miscellaneous - there are other potential benefits as well - such as keeping all the sql code where the dba can automate access plan creation, impact analysis, etc. Another misc benefit is in the creation of a security layer.
Of course, note that in none of the above scenarios am I recommending large or complex stored procedures. The kind I'm recommending are 99% sql - and easily port from one database to another.