Thread: MySQL at .NET conference

MySQL at .NET conference

From
mlw
Date:
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."




Re: MySQL at .NET conference

From
"Christopher Kings-Lynne"
Date:
> 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



Re: [GENERAL] MySQL at .NET conference

From
"scott.marlowe"
Date:
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.


Re: MySQL at .NET conference

From
"Merlin Moncure"
Date:
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