New SQL Server Release Slips to 2005 430
Strudelkugel writes "CRN reports SQL Server 'Yukon' will slip to 2005, complicating plans for ISVs and creating opportunities for OSS and other competitors."
We are each entitled to our own opinion, but no one is entitled to his own facts. -- Patrick Moynihan
That's okay (Score:2, Interesting)
Who needs all that integrated
Re:That's okay (Score:2, Insightful)
Re: (Score:3, Insightful)
Re:That's okay (Score:5, Insightful)
I'm sorry, but what the hell are you talking about? I've used both these servers extensively (as well as Sybase ASA, PostgreSQL and Oracle), and as much as I respect MySQL, it's certainly no easier to use than SQL Server. It's at best about the same, with SQL Server being much easier to pick up from 0 knowledge due to a surprisingly good set of help docs. Enterprise Manager and Query Analyzer are really good tools, as well...in fact, until we discovered mssqlXpress [xpressapps.com], Query Analyzer was bar none my favorite IDE for making new statements. (sqlXpress adds sourcesafe integration, versioning, and historical reporting to a clone of Q.A. with autocomplete and automatic proc generation, it is a pretty clutch tool)
MySQL is very good, but ten times better? Not really. In fact, if I had to beg for any SQL Server regardless of price, I'd take SQL Server because it's the easiest to develop for and easiest to port FROM. This gives you an app that will run on almost any other server with a little effort. I rewrote a massive app to run on Sybase in three weeks and Postgres in a month (most of which was testing the DB core of our app).
Re:That's okay (Score:3, Interesting)
For open source..I'm still looking into it, but, I like PostgreSQL the best at this point..good data integrity...very oracle like....
Re:That's okay (Score:5, Informative)
Re:That's okay (Score:3, Informative)
Re:That's okay (Score:5, Insightful)
1. Easy to install on Windows. The average coder at a Windows-only farm can easily run the executable and have the latest version running on their developer box. Not all companies allow you to have multiple boxes, and many force you (via draconion security measures) to only run windows with certain software installed. Postgres NEEDS a user-friendly Win32 installer, perhaps with a similar info-item like MySQL has. This is a MUST for companies to start to take notice. Then, a PHB can even play with it and like it.
2. Marketing. While open-source, MySQL has a nice marketing engine behind it. A beautiful webpage, online and PRINT adds, and magazine and newspaper articles CONSTANTLY writing about the "little database that could" every few week / months. Postgres needs to start getting the word out, and hype it a little. Just because a product is superior, doesn't mean it will thrive. There are tons of examples out there: Beta vs VHS, Windows vs OS X, etc. For a database to be used, it must be allowed and "signed off" by a manager of some sort. Most will take reputation + support + "ooh, nice webpage" over a product that might be better, but they know nothing about it.
3. More management tools. MySQL has a couple out there that look and run great; very professional looking. This earns respect from PHB's, as they are easily misled by such niceties.
Don't get me wrong. MySQL is nice, but doesn't have what I need most (Views, triggers, etc). Postgres may not be perfect, but I think it is superior. We just need to get the word out to those "not in the know".
Re:That's okay (Score:5, Insightful)
Unfortunately my job runs SQL Server 2000. Having cut my teeth on PL/SQL, Transact is a nightmare because it is so limiting.
I'm actually looking forward to Yukon because the marketing ad sheet shows some really cool features. The only question is will they deliver and when will it be?
Oracle and DB2 (Score:3, Informative)
Download Oracle [slashdot.org] or DB2 [ibm.com] 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...
Re:That's okay (Score:3, Funny)
I especially like that feature where every SQL Server communicates with each other... what's it called? Oh yeah, SQL SLAMMER.
'best database around for the price'? (Score:4, Interesting)
Is it the best database for a linux or unix shop?
Is it the best database for large reporting or search applications?
Is it the best database for projects or companies with a small budget?
Ah, the answer to all of the above is 'no':
- zero portability
- parallelism and partitioning is primitive
- licensing costs for a 4-way server can easily hit $100k, and in many configurations are more expensive than other top commercial products (db2 for example).
When it comes to prototyping, sql server is at the top of my list. However, when it comes to delivering powerful capabilities, automating operations, and scripting changes - then it's at the bottom of my list.
But I will agree with you on the
Re:BLASPHEMY! BLASPHEMY! YOU WILL EMBRACE MYSQL! (Score:2)
If MySQL really did just get transaction support, it seems more like My was a bit behind, rather than being far ahead of the others.
Re:BLASPHEMY! BLASPHEMY! YOU WILL EMBRACE MYSQL! (Score:5, Interesting)
I have since got over my shock and realised that MySql is really good for what it is, but is really a different kind of beast to Oracle, MSSql etc.
Dan.
Re:BLASPHEMY! BLASPHEMY! YOU WILL EMBRACE MYSQL! (Score:4, Informative)
Re:That's okay (Score:2, Insightful)
no way! MySQL will always have it's place: it's an open source alternative and i'd also guess it would have a predominantly different market.
Re:That's okay - Holy cow 40 Million lines of code (Score:5, Insightful)
Just out of curiosity, I counted the lines of code (both c & assembler, all processors) of the 2.6.4 kernel. It is less than 5.5 million.
40 million lines of code. There's all the reason I ever need to not use it.
With 40 million lines of code, you never fix bugs, the best you can hope for is to relocate them to a really obscure place.
Re:That's okay - Holy cow 40 Million lines of code (Score:3, Insightful)
grow beyond ms sql 6.5 (Score:3, Insightful)
>databases because 2000 still has some problems.
>the only other database they use is Oracle, and
>MSSQL is a tiny joke of a toy compared to it.
I suppose you have never run SQL 2000 on a decently powerful machine.
I also suppose you never put a load balancing application on top of a dozen or so SQL 2000 boxes.
Get over it. SQL 2000 is on par with Oracle, Sybase, DB2, etc.
Yukon's promised features (Score:4, Interesting)
Disappointing. SQL Server had really come a long way, too. Maybe 2005 won't be too late.
Re:Yukon's promised features (Score:4, Insightful)
Let's face it, these features isn't something most users need. If Microsoft sees real trouble, they will simply slash the per-processor license cost by a factor of 50 or 100, and switching suddenly becomes a non-issue for most users.
Per-client licenses and awfully high per-processor licensing costs are the most important factor which motivates most users to attempt other solutions. Of course, the proprietary databases have important features which look very good on paper, but I've seen quite a few installations which use a multi-thousand dollar database as if it were MySQL (not even using online backup). You can get away with that if you only need a workgroup server license, but if you need 20,000 client access licenses (or multiple per-processor licenses), licensing becomes a problem and you'll certainly consider other options.
Re:Yukon's promised features (Score:3, Interesting)
Re:Yukon's promised features (Score:3, Insightful)
And much of the speed boost you see in using SQL instead of a flat file is in the compilation of stored procedures. Which is
What ... (Score:2, Interesting)
Re:What ... (Score:5, Interesting)
Yukon will allow structs as column types, and will do mapping between
Longhorn replaces Win32 with
There, I said it. 2007.
Re:What ... (Score:5, Insightful)
Just what you need a new microsoft database that makes refactoring and porting your DB to another platform near impossible.
Larry Elison is probably chuckling like a demented monkey over this. I can see his sales people going at this. Microsoft Software assurance = Pay them to take their time to devise ways to achieve complete customer lock in. Or, the ever popular why run your business using techniques with 50 years of validation behind them when you can do things microsofts way.
I can allready see the security problems popping up. Run C# code directly, the same code being ever more integrated into yukon. Well seems we will be able to expect worms that make slammer look like a joke. Heck you could have them replicate throughout the entire system and hold entire enterprises data hostage.
The sad thing is that the large group of IT director/ Sysadmin lemmings will go along with no one ever got fired for choosing microsoft. After all, look at how they have embraced the ever popular and ever more dangerous office/exchange combo.
Re:What ... (Score:4, Insightful)
Same code, but different security model/sandbox. The CLR in yukon does not have access to the file system, sockets, winforms, services, the registry or anything else a virus is going to need. It's limited to communicating with the SQL process and manipulating data within a database. Nothing more.
Re:What ... (Score:2)
That trend started long ago in a galaxy quite close.
The filesystems as database feature has been touted for NT, Xp and now Longhorn.
Software companies are in a dilemma, dammned if you pre-announce, dammned if you don't.
Following their roadmap is the road to hell.
and grrrr lose not loose, fool
Re:What ... (Score:5, Insightful)
Lets just hope OSS developers don't sit on their laurels during these delays. If they do they will be playing major catch up come 2005/2006. This is the time for OSS to take the lead. The boys at Redmond may be evil, but they are no fools.
Re:What ... (Score:4, Insightful)
Unfortunately, as far as I can see (and my idea will be readily disputed by others) no OSS database is ready for "enterprise" systems (whatever that means, I work in a company who writes software and the backend can be any RDMBS as long as they have a decend JDBC driver). SQL Server 2k has lots of missing features which makes our life very hard and I'm not a fan but at the moment I can't go to any of our customers and say use postgres or mySQL etc.
Another big player is DB2 by IBM which claims it has the fastest database on the world but DB2 is cumbersome, hard to manage compared to Oracle and MS SQL2k but it works almost under any platform under the sun.
Database world is quite interesting, I can't say any RDMS system out there is perfect.
OSS Opportunity (Score:5, Interesting)
It's also worth the effort on Microsofts' part to get this right. After all, WinFS [microsoft.com] is going to be built on the same technology.
Re:OSS Opportunity (Score:3, Interesting)
I'd be surprised if any company of size would change something as mission critical as their DBMS due to this delay. To me, it says that they're going to get it right first time around
I agree with you about large company decisions remaining unchanged. But I have not ever seen a significant correlation between slipping release dates and improved quality - in fact, my experience says the opposite. Maybe SQL Server will be the exception, but I doubt it.
Editorial license (Score:5, Interesting)
Today I learned something about
I have a suspicion that institutional investors in Microsoft are having their patience tested with a stock price that hasn't moved, no clear vision being stated by the company (remember .Net everything?) and no official statement about how the cash hoard will be used. Unlike OSS, Microsoft has investors that can and will influence the direction of the company.
If institutions force Ballmer out, what strategy will Microsoft pursue, and what might this mean for technology? That was the question I wanted to address. Ironically, I even stated in my post that I didn't want this to become another Microsoft v. OSS story, as there are plenty of those already. The business problems of Ballmer might not seem to be a technical story, but I think they absolutely are, as whatever Microsoft does to satisfy its big investors will have great significance for the tech world.
but (Score:5, Insightful)
One thing anyone in the IT business should learn is to never ever under estimate microsoft.
except... (Score:5, Interesting)
These companies are going to be extremely p155ed off when they realise that all they are going to get for their money is (maybe) XP Reloaded (think ME).
Companies cannot afford to throw money down the microsoft toilet for much longer... especially when all they get is extra bugs that they didnt need in the first place, coupled with a healthy dose of lock-in and increased support costs.
Re:but (Score:2)
We shouldn't "support" microsoft for this unless they come out with one hell of a product in the end (and we know they won't.)
Re:but (Score:4, Insightful)
Look, what are you waiting for in the next release of SQLServer? Anything? Nope...didn't think so.
You HAVE a rock-solid DB solution from MS right now, so who cares if the next release from MS is late, especially when it represents a fundamental change, and thus nothing you're doing _right now_ will suffer if it's not out next week will it?
Damned, the only thing I know of that's being worked on that requires this to be released is WinFS, which will be released in Longhorn when? A couple more years you say?
Besides, when was the last time your OSS project of choice went gold on time? And no, not having release deadlines doesn't count.
Re:but (Score:2, Funny)
A few years ago, I would have agreed with you. Now my response is:
Ooooh Microsoft is mad at me, I'm so scared! Microsoft is coming to get me! Oh no, don't let Microsoft come after me! They're so big and strong! Oh, protect me from Microsoft!
(Thanks to MrBurns)
Like what? (Score:3, Interesting)
Re:Like what? (Score:2)
There's one entity that could actually consider this an opportunity.
Re:Like what? (Score:5, Insightful)
How about ANSI '92 compliance for MySQL... that would be a good start!
No, a good start would be to flush MySQL down the toilet where it belongs and use a real database engine such as PostgreSQL or Firebird.
Seriously! Why wait for MySQL to add all those missing features when such superior alternatives already exist, and, furthermore, MySQL has a more restrictive license?
Re:Like what? (Score:5, Insightful)
As long as you can accept the limitations of MySQL, it's perfectly usable. MySQL is faster and lighter weight than PostgreSQL in my experience. I haven't tried Firebird yet.
Honestly, I wouldn't want to run a site like Slashdot on MySQL, but for smaller projects it seems useful.
RDBMSes don't implement Codd's 12 rules anyway, so maybe none of them are "real". Personally I think it's good to have a range of database options. At the high end, Oracle and DB2 have loads of features, and are presumably "real" by your definition, but they are also incredibly complex to administrate, which is why most companies have dedicated DBAs for them.
maybe (Score:4, Interesting)
Re:maybe (Score:3, Insightful)
Meanwhile some of poor DBA have to work with a product which was lacking major database capabilites when it was released, and now have to tell managers they the capabilities and money they were expecting for 2004 will
MS slips makes more opportunities? (Score:5, Insightful)
Just because the product isn't there doesn't mean they will automatically go to another 'free' alternative- instead it means they'll simply use the older version until it wears out.
Obviously you don't know the situation (Score:4, Insightful)
That means... they tell us to build the system to operate on it, and we deliver.
Coming back to them and informing them we aren't going to listen to their needs would result in, oh, someone else having been awarded the contract.
Actualy kind of sad (Score:5, Interesting)
7.0 was a huge jump from 6.5 and 2k from 7.0 was almost as significant of a jump. I will call a spade a spade and say that the evolution of the MS SQL server has really impressed me and I was looking for good things from this next version as well. I know this is the wrong place to say such things, but I've had lots of problems with other MS problems, but this one since 7.0 has been quite good. Don't even get me started on some of their other products though.
I'll just go hide in my DBA hole until 2005 I guess.
Re:Actualy kind of sad (Score:2)
Re:Actualy kind of sad (Score:4, Interesting)
I do hope they can somehow do a better job with security with the next release, although that may be asking too much. :-( Last time I had to reinstall SQL Server 2000, the whole subnet was down with the SQL Slammer worm before I even had a chance to configure the server and download the patches from Microsoft. Ouch. You have to download the patches ahead of time, pull the server off the internet, install SQL Server and all the patches, change the default port (and obviously make sure your sa password is not blank, duh) and only THEN go back online. Wow.
Re:Actualy kind of sad (Score:3, Informative)
In any rate, Sybase ASE uses the T-SQL dialect and also has many of the same stored procedures for system administration.
Re:Actualy kind of sad (Score:3, Insightful)
We had an incompetent admin and were vulnerable to Slammer for over a year on four major DB servers at our colo facility. Even though our new admin compared the firewall to sieve, it was still secure enough to protect us. I think we were vrey lucky, but I find it hard to believe that you can bring up SQL Server i
Re:Actualy kind of sad (Score:3, Interesting)
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.
Is it just because the gui tools make it easier or something?
Re:Actualy kind of sad (Score:4, Informative)
Re:Actualy kind of sad (Score:4, Informative)
> 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.
Meanwhile, MySQL does transactions (Score:5, Informative)
--Mike--
Re:Meanwhile, MySQL does transactions (Score:3, Insightful)
If you used real databases, in real production environments on complex data sets, you'd see that MySQL just doesn't cut it - yet. It's great for trivial 'simple but big' datasets, but for data mining and analysis it's awful.
Re:Meanwhile, MySQL does transactions (Score:5, Insightful)
Why not use Postgres? That way, you don't have to wait for features that all the other RDBMS products have had for years. What is it that makes MySQL so much more popular than Postgres? It sure isn't features.
Re:Meanwhile, MySQL does transactions (Score:3, Insightful)
The same with MySQL, at around 1999 when I first started to look at doing some (very simple) database work it was the most developed thing you could get for free. At that time, Postgres was not optimised for speed and was still regarded as research product.
Anyhow, the situation has changed somewhat but some people still think it's 1999, of course most of these people are n't RDBMS peo
Re:Meanwhile, MySQL does transactions (Score:5, Insightful)
Lower barrier to entry.
Since the vast majority of toy applications don't
need anything more than a hashed flat file (like gdbm), people find it easy
to get things working with MySQL (MySQL abstracts a flat file quite easily)
and suddenly think they're Database GODS. Then, when they attempt a new
db project, they either force MySQL into it because it's what they know, or
they look at a more powerful DB package, realize they're in over their head,
and decide that the DB package is to blame for their inability to use it, thus
reinforcing their idea that MySQL is a better tool.
Now I realize that there are lots of applications where MySQL is perfectly
adequate, but the ease of using MySQL for toy applications has fooled lots
of people who have limited db skills at best into thinking that they're
experts.
Re:Meanwhile, MySQL does transactions (Score:5, Insightful)
Jeez. First time I looked at MySQL a couple of years ago for a project I started putting a basic database scheme together an went to construct a view, only for my Jaw to hit the desk when I found out they were not available. Views are such a basic component of RDBMS databases that it simply hadn't occurred to me (an Oracle, DB2, SQLServer and others veteran) that software could be release that called itself a relational database that didn't have them.
Anyway, just went and used Postgres instead. It's still beyond me why people even bother giving MySQL the time of day when the incomparably superior Postgres is available under GPL.
Re:Meanwhile, MySQL does transactions (Score:5, Insightful)
I'm with you on that one. Once I installed Postgres I haven't looked back. What I admire about the Postgres team is that they focus on standards first and speed second. Smart, because eventually speed catches up (through code optimization or just over time through hardware); whereas MySQL has to add in features afterwards, and do so without slowing it down (and thus pissing off its following). Please MySQL fans, no flaming.
Postgres vs. MS SQL is sort of a different issue. MS SQL has all kinds of features Postgres doesn't have, e.g. lots of replication features (I believe, though I've never had to use them) and its optimizer seems more intelligent than Postgres'. That said, very few dataservers actually use the extended features, and my casual complaints about Postgres' optimizer are quelled by a) fixing my query b) VACUUMing the database as instructed or c) realizing that it was only a few ms slower anyway. Cons on the MS SQL Server side are that a) it ties to you one platform, b) tends to have large gaping security holes and c) tends more often to be implemented by those without a clue of DBAing or security.
Whoops, I ranted.
Re:Meanwhile, MySQL does transactions (Score:4, Insightful)
There's nothing as gratifying when working on a project as realizing that you've built such a solid, engineered solution that you can throw out five layers of error checking that test for conditions that you can rigorously prove cannot exist. Those are the sorts of speedups that PostgreSQL has been undergoing, and even if I didn't like PostgreSQL as a product, I would certainly commend their design team for such excellent work.
Re:Meanwhile, MySQL does transactions (Score:5, Funny)
Slashdot rule #12: comments on any story even remotely related to database systems will ultimately digress into a MySQL vs. PostgreSQL advocacy war.
Re:Meanwhile, MySQL does transactions (Score:3, Insightful)
Try Firebird. (Score:3, Interesting)
Ben is Glory! Wake up people!
Anyway, check out Firebird. It's way ahead of Postgres on most counts.
-Graham
Re:postgres vs mysql (Score:3, Insightful)
It has plenty of momentum, and is clearly ready and getting used in a wide variety of applications now.
MySQL does have an incredible amount of momentum, more than most products out there. However, it'll have to be completely rewritten from the ground up before it really becomes a threat to commercial products. That will probably take years to get right. Postgresql on
MS helping OSS - Indirectly (Score:5, Insightful)
Re:MS helping OSS - Indirectly (Score:3, Informative)
Postgresql [postgresql.com]
Maxdb [mysql.com]
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.
Re:MS helping OSS - Indirectly (Score:3, Informative)
Updates to Views
Real Time Replication
Two Phase Commit
OSS databases often make good substitutes (Score:3, Insightful)
I agree with you to an extent, although moreso for Postgres than MySQL, the latter of which is insulting and not worthy of being labelled a real database, imho.
I also think that this is exactly why open source is such a threat to the big products like Oracle and SQL Server. The big databases certainly do have a lot of features. Certainly they're capable of much more than open source products. But if
Does this sound familiar? (Score:4, Funny)
Uh huh...I see that's working out nicely...
Just More Validation for OSS Model (Score:3, Insightful)
Meanwhile, the groups that produce products like MySQL and PostgreSQL have had steady releases, a wealth of needed features, and relatively few security incidents.
Unless you're already so heavily bought in to their infrastructure that any change would be prohibitively expensive, I can't see how it makes any sense to base your business on Microsoft's products. They're expensive, they're insecure, they're performance laggards, and you just can't rely on them for support.
Cheers,
Past tense? (Score:5, Informative)
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".
Re: (Score:3, Insightful)
Re:Past tense? (Score:4, Insightful)
Oh, you mean the wonderful deal where you pay for the priviledge of being a beta tester?
Can't screw up (Score:5, Insightful)
Businesses may run on one of their OSes, but businesses run IN SQL Server. This product can make or (more critically) brake businesses. If rumors of major problems with SQL server screwing up business were to get out, corporate perception of them would tank.
They have no real choice with this product but to try and make sure it is ready (and take more time if needed) rather than push it to market.
-Pete
Mysql, PosteGres, DB2, Oracle MSSQL (Score:5, Informative)
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
Slashdot - MySQL? (Score:4, Informative)
Re:Slashdot - MySQL? (Score:4, Funny)
Re:Slashdot - MySQL? (Score:3, Flamebait)
My god, thinking about Slashcode alone makes my eyes bleed. I don't even want to think about their InnoDB setup.
I remember some guy posted about how switching to CSS would save around 20-40% or so of bandwidth. Taco's response? "Submit a patch if you want." So we're stuck with HTML 3.2 because Taco is a lazy ass who doesn't want to fix it himself.
Re:Slashdot - MySQL? (Score:5, Insightful)
And Microsoft.com runs on IIS -- but that doesn't mean that IIS is everything to everyone; nor does the fact that Slashdot runs on MySQL mean that MySQL is good for everyone.
MySQL is really good at a really limited subset of queries. If MySQL is all you know, then your ignorance is bliss in that you don't know all the other wonderful things a real RDBMS can do for you since MySQL never offered them to you.
Once you've used a real database system, you could never go back to the chains of MySQL.
Re:Mysql, PosteGres, DB2, Oracle MSSQL (Score:3, Interesting)
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.
It looks to me that your "25 year old self proclaimed web genius" is exactly that. And doesn't know the first thing about databases, let alone operating systems, process slots, filehandles, semaphore locks, interrupts or Context switches. And is absolutely clueless about how to debug DB performance problems.
There *is* one thing that MySQL is good at a
Re:Mysql, PosteGres, DB2, Oracle MSSQL (Score:4, Insightful)
Whoa. MySQL is only good at "performance" under very simplistic use cases (single table selects, low insert/update load). Which describes a web board, but not that many real world applications. I'm sure this is one of the perceptions that the guy is fighting with -- that "MySQL is teh fasterest", when in fact with their applicaiton which is obviously designed for real DB servers, it isn't.
Horrible Name (Score:4, Insightful)
What's so generic about it? (Score:3, Insightful)
Oh--"mickysoft?" What is this, a high school Linux user group in 1998?
SQL 2005 & VS.NET 2005 (Score:5, Interesting)
The thing I don't understand is why VS.NET is being delayed like this, the SQL objects should be seperate and not integrated into VS.Net anyway!
SQL Server 2005, Visual Studio 2005 (Score:5, Informative)
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 delivery [com.com]marketing survey (Score:3, Interesting)
I said no because:
1) it was too tighly integrated into AD/ windows server and we didn't any of that.
2) I didn't trust it, and wouldn't till it had been in the field for at least a year.
I think they got alot of responses like 2) (going by the marketers comments) and they prob decided to wait till the new windows server is out (2006??) and deploy on the new Trusted Computing Base thing they are wittering on about.
Some of that Spit and Polish (Score:5, Insightful)
Much as I love a good MS Bashing, I'll tell you what I find really lacking (personally) for PostgreSQL and other OSS RDBMSs - a good GUI management tool.
Something that helps you craft medium-complicated joins quickly with a few clicks and drags.
For example, see this screenshot [phrogz.net] from Visual Interdev working on MSSQL2k, creating a SQL Query for a stored proc. Sure, it's almost trivial to hand-write the SQL code. But it was even easier to just select a few tables, click on the fields I want, right-click on the joins (created automatically from the database structure) to change their type, and be done.
I use PGSQL for all my personal projects now, but I sorely miss the speed that a GUI editor like this allowed me.
The real problem (Score:5, Interesting)
To top it off, MS is not even going to be releasing any service packs for Visual Studio in the meantime. There are some rather serious issues with the current version of Visual Studio that can only be fixed by calling MS for specific hotfixes. Needless to say, much of the MS developer community is up in arms.
Re:The real problem (Score:3, Insightful)
The reason they must ship together is because SQL Server is the guinea pig for Whidbey's new hosting interfaces (running an instance of the Framework inside your own non-managed application). This is not a trivial addition to the
Check
Not a great loss.. SQL2000 is a good product (Score:3, Interesting)
Its one of the few solid things that microsoft puts out. Previous verisons were pretty dismal.
I doubt that most pepole will ever need the 'new' features coming down the pike. They should leave it alone, instead of screwing it up or bloating it out....
It wasn't... (Score:4, Informative)
Please called it MICROSOFT SQL server (Score:3, Insightful)
program that serves SQL.
Old News (Score:3, Informative)
http://www.microsoft-watch.com/article2/0,1995,
Steven
Why Analysts Suck. (Score:3, Insightful)
Betsy clearly has no clue regarding the SQL Server product's evolution, capabilites or how these are going to change with Yukon. In fact she seems to have a very limited grasp of significance of the Yukon's release.
Unlike Oracle, SQL Server has basically hovered in the "if it ain't broke don't fix it" pattern for the last 5 years. For the most part it has delivered a decent database platform, that was for a while more cost effective than oracle. Those who have used SQL Server extensively know it's limitations. Betsy's arguments about "product lacking focus" are rediculous. That's primarily becuase Yukon seeks to rectify a large number of the problems and limitations of SQL Server 2k. It's really very difficult to provide a "focused" look at a product that is changing so significantly. In fact, her complaint is very similar to those that were uttered as Microsfot was trying to formalize the definition of
It would seem that Betsy is looking for are a few jargon sound bytes that can be displayed on a single powerpoint slide. That slide would then be shown to a bunch of people who nod their head and say, "that's a sound strategic driection". Big idea's aren't sound bytes.
Unfortunately for Microsoft, they are attempting to be ambitious with Yukon. A lot of new plumbing is going in, as well as a refinement and crystalization of the current features such as SQL -> XML queries, DTS, Replication, the integration of a first class programming language among others. These are all features that we've needed for a long time.
Yukon represents a significant change in the world of RDMS's on the Windows platform. It's sad to see that influential groups such as Gartner can't recognize or have the vision to see how much (and for the better) things are going to change for SQL Server 2K shops.
Re:OS RDBMS might profit (Score:3, Insightful)
Wow, MySQL now has an official front-end tool (instead of one of many third-party ones that it's had for ages), oohh, that'll make ALL the difference. It's got NOWHERE NEAR the feature set of MS-SQL, Oracle, PostgreSQL, or Firebird. Christ, we had to wait till version FOUR till they added native transaction support (which wasn't ever written by them), subqueries, replication, etc. and we're still not sure that it even does any of this properly now! (Each point relea
Re:OS RDBMS might profit (Score:3, Interesting)
You talk about people who don't know shit about databases, but you know so much that you had to post anonymously. You clearly don't know shit about MySQL.
You're right that MySQL doesn't have all the features that Oracle and DB2 have, but those two databases don't have all the features that MySQL has. MySQL let's you tailor your databases/table types to what they are going to be used for. You can pick and even change on the fly the algorithm used for your tables.
Re:This product lacks focus (Score:3, Insightful)
True, and the 'troops' here are not only the programmers, but also the MS marketers and MS development community. XML features? .NET stuff? I am all in favor of having options, but I cannot imagine that each and every feature will be well-optimized or secure. MS SQL, which is and has been one of MS' best products, is going the way of Word by incorporating a bajilli
Re:argh! can't wait (Score:3, Informative)
> 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 ha