Thread: MySQL at .NET conference
I had the misfortune of having to attend a .NET forum. It was interesting, it seems like Microsoft is gonna may anyone's dog able to write web service applications. The catch being that it will only run on Windows .NET. Anyway, on to MySQL. The had a booth there. I asked their technical guy a few questions and he seemed to have a decent understanding. When I asked the question, "Why would I choose MySQL over something like PostgreSQL?" his response was "There is one company driving MySQL. Also, when we do a feature we think it through and deliver it completed. The PostgreSQL group tends to deliver things that aren't quite right or incomplete." I was taken aback by this. I don't think it is completely true, but I wonder what you guys think. Lastly, I asked are there any technical reasons why I would use MySQL over PostgreSQL, and the guy answered "not really."
> Anyway, on to MySQL. The had a booth there. I asked their technical guy > a few questions and he seemed to have a decent understanding. When I > asked the question, "Why would I choose MySQL over something like > PostgreSQL?" his response was "There is one company driving MySQL. Also, > when we do a feature we think it through and deliver it completed. The > PostgreSQL group tends to deliver things that aren't quite right or > incomplete." I was taken aback by this. I don't think it is completely > true, but I wonder what you guys think. I think it's substantially true :) Chris
On Wed, 19 Mar 2003, mlw wrote: > Anyway, on to MySQL. The had a booth there. I asked their technical guy > a few questions and he seemed to have a decent understanding. When I > asked the question, "Why would I choose MySQL over something like > PostgreSQL?" his response was "There is one company driving MySQL. Also, > when we do a feature we think it through and deliver it completed. The > PostgreSQL group tends to deliver things that aren't quite right or > incomplete." I was taken aback by this. I don't think it is completely > true, but I wonder what you guys think. It's interesting how they paint their development style as superior to Postgresql's. Personally, I prefer the way postgresql does it. they release lots of betas to play with and I can test it myself three sub versions before it becomes a standard release and report back bugs during development, not afterwards. They also hint that Postgresql is released this way all the time, i.e. there are tons of untested features in the 7.3.0 release no one's ever seen before. If they were around for the beta testing they saw them over and over. They were tested by more eyes than MySQL beta features often are, and they were tested well. Keep in mind, they're still adding basic features like transactions and sub queries that postgresql has had for ages. Lastly, I'd say having one company drive your database is not necessarily a good thing. If MySQL wants to zig and you want to zag, then tough, there's no backup plan. If I REALLY have to have PITR or something, I can have the finance guys cut a check to any of a half dozen postgresql hackers and know that it will get done. If the MySQL team doesn't want it you may not be able to get it done, as there aren't a lot of hackers on MySQL outside of their core team. > Lastly, I asked are there any technical reasons why I would use MySQL > over PostgreSQL, and the guy answered "not really." I can even think of a few, buily in replication, built in full text search. OK, that's it, but still, I can think of a couple, and I'm not a MySQL expert.
mlw wrote: > I had the misfortune of having to attend a .NET forum. It was > interesting, it seems like Microsoft is gonna may anyone's dog able to > write web service applications. The catch being that it will only run on > Windows .NET. Ah, so you were in heck: how was the weather? Seriously, .NET is an interesting platform on many different levels. I think the database layer, ado.net, should be regarded with great suspicion because at some point Microsoft is going to release an OS level data server which will deal directly with the ADO.NET dataset objects and bypass the traditional sql server. Once complete, this 'server' will feed data as raw xml or xml in a quasi-proprietary format, not traditional tabular sql result sets. As it stands right now, they made it deliberately difficult to leverage features from the database outside of queries and transactions. The architecture strongly encourages a disconnected 3-tier model with most of the action happening via c# code, not database widgets. To me, they kind of overdid things and this is hurting .net's adoption by the larger pool of database developers. This is kind of tragic, because C# is an extremely well designed language, even beautiful (designed by the same genius who came up with delpi, btw). In the future, (should Microsoft's plans reach fruition) it is reasonable to conjecture that database needs filled by access right now might no longer require a packaged 'database' engine but would only be a collection of wizards for using the native file system. I think their plans will likely fail because they overestimated: a. IT manager's unhappiness with standard 2-tier client-server data models for small and medium installations, b. enterprise manager's desire to switch gears adopt a new platform (from j2ee, and c: developer support for an xml driven data engine. As for MySQL, the idea of that database providing ado.net enterprise apps is pretty much a joke to me, not much else to say about that. One point about your comment: asp.net + ado.net + IIS (or apache) does not require .net on the client platform (at least right now), unless you return .net objects inline to your web page (like activex), or use client side C# scripting. This deserves clarification because you brought this up in the context of web service applications which can be written for any platform, even linux as the desktop target. Merlin