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
Actually, if you're looking to blame someone for the name, blame Sybase.
MS SQL Server started out as a partnership between MS and Sybase to port Sybase's flagship database project (called "SQL Server") to Microsoft's OS/2 offering in 1987. This eventually turned into the first version of SQL Server for NT in 1992.
Both sides agreed to end their joint development agreement in 1994. For a time, both companies released products named SQL Server, which led to the expected confusion among PHBs.
Finally, after MS SQL Server started taking over market share, Sybase changed the name of its flagship RDBMS product to Adaptive Server Enterprise (ASE), leaving MS in sole possession of Sybase's original product name.
[Source for all this info is Inside SQL Server 2000, I believe it's based on a foreword by Jim Gray from an earlier version of this reference]
This product lacks focus," said Betsy Burton, analyst with the Gartner Group. "They're doing all sorts of stuff with it, first scalability was the issue, then XML support, then .Net activities, and then business intelligence and now security. The gut issue is, what is the purpose of this release? As a team trying to develop a product you have to know where you're going," she said.
This is the paragraph that explains it all. This product lacks focus. Why? Who knows? But if you cannot give your troops clear, concise goals, then everyone will go in a million different directions. And nothing will get done!
When this project first started out, it may have had the clear, concise goals. But then they started to add extra things to the project as it progressed. Sometimes adding a new feature or what-not means starting from scratch (if you wanna do it right).
If MS wants to do this right (and not delay the shipping date), then they should put a freeze on adding new features. Otherwise, it will either slip again, or a critical flaw will be found with the software.
My $0.02
It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.
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
Uh, most DBAs that I know just call it MS-SQL (emm-ess sequel)?
> SQL Server 2005? is going to be great. However, if I had to choose the *best* database I would go with > Oracle without a doubt. Every tool other database manufacturers are trying to mirror > generally come from Oracle. Ah, no. Most of the BI functionality being implemented in RDBMS' over the last 4-8 years was first implemented in teradata & then informix. And "Best" makes no sense without context. Oracle is very powerful, but relies heavily on experienced and available dbas, and is the most expensive product out there. Best for some folks might be a less expensive product or simpler product to manage. And as far as performance is concerned both teradata & db2 beat it out at the extreme top end.
Well, Postgres which is the one I know most about doesn't have:
Updates to Views
Real Time Replication
Two Phase Commit
--- These are not words: wierd, genious, rediculous
slated to be released until the last quarter this year. 2005 "sounds bad", but it's only a few months.
Yep, I was shocked when I first played with MySql, having heard such good things about it, and discovered how many features it lacked that I consider essential to a serious database.
Have you seen versions 4.0, 4.1 or 5.0? True, 3.23 did lack many essential features.
The ship date news had already been reported by Mary Jo Foley, The reporter of Microsoft news, on the 10th.
1 54 6601,00.asp
http://www.microsoft-watch.com/article2/0,1995,
Steven
> For those Oracle lovers in the crowd, take a look at the benchmarks - MS SQL rules the lower and middle
> ground. It would rule the high end except lack of platform has held it back.
um, which benchmarks would those be? www.tpc.org doesn't have many benchmarks for desktop-sized servers (which is where sql server really does beat oracle/db2/etc). And as far as it being held back by its platform - without any of the parallel features of oracle/db2, and without any of the partitioning features - it has zero chance at the high-end.
It's basically *years* behind either of those two databases. This has nothing to do with windows, it has everything to do with lack of high-end database features in sql server. Microsoft has done a good job of improving the database client UI and adding usability features to low-end database functionality. But it hasn't added the high-end functionality, nor has it really delivered a great UI (for example: the SQL Server GUIs all sort date columns alphabetically rather than cronologically).
> Yukon is going to kill Oracle in the middle space because of development features.
Got news for ya, people pick databases for reasons other than development features.
Don't know, the last version I bought was Office 97. For what we use it for, there is no added value to upgrading.
By skipping Office 2000, Office XP and Office 2003, we saved mucho $$$.
WTF? Over?
How do you figure that Firebird is "way ahead" of PostgreSQL? It's better than MySQL sure, and it has some abilties that PG doesn't (a Windows version and it can be embedded), but I wouldn't say that it's "way ahead."
As far as Oracle, I haven't seen anyone use it based on Oracle's technical merit. The only reason I ever hear to use 9i is that it has "market share". It's hard to manage, it's inconsistent, convoluted, and just plain difficult to work with. The limitations of PL/SQL, SQL*Plus and Server SQL are amazing -- there's no 'if' statement, and you can't write DDL with it.
One database per server. Index creation gets logged and can fail (hanging indefintely) if the log fills up. The 'create database' command doesn't yield a functional database. Oracle is an absolute pig with system resources -- worse than Microsoft. It's data replication is terrible. It's a real mess.
If you're looking for a linux-friendly database, look at Sybase ASE 12.5, the LinuxWorld Reader's Choice awardee. You'll find it less expensive than Oracle or MSSQL, also.
Download Oracle or DB2 today.
This is really helpful if you want to play around or learn them, but you need to have a pretty big machine to put them on. Figure on 1GB RAM, 2GB swap and at least 20GB disk, just to play around with ONE of them. Then add in the size of the data you'll be working with...
How am I supposed to fit a pithy, relevant quote into 120 characters?
Wrong... Institutional investors have much more stock, and they can heavily influence Microsoft direction. See here
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.
You're an idiot. If you had any sense you'd be applying the argument to PostgreSQL vs MSSQL, and leaving mySQL the fuck out of it. You obviously don't have a clue what goes into a good database.
Shit, have we all regressed back to the 80s here?
mySQL is barely better than using, say, C-ISAM. Technology has moved on since then. You would save yourself one hell of a lot of development time by using a decent database with modern features.
PostgreSQL, for example, is an very good candidate if you don't want to shell out hundreds of dollars.