Just to stop this degenerating into a "my daddy can beat your daddy" debate, the point is all RDMS have got pros and cons so defending one over another is a never ending tale. That war has been fought and the battle still rages on however, i just want to make to points here. the terrabyte data relication i mentioned is when using snapshot method on sqlserver which is known to be time consuming... not necessarily for large datasets but its generally time consuming. I donno if you have tried using it.
 
Now about the storage engine your choice of storage engines can be misinformed... Let me pick on your scenario. You want a feature on MYISAM and another from INNODB. The solution is simple try out the MARIADB Storage Engine it is has adopted the features of INNODB and merged them with features from MYISAM. Now the current branch we are working on even picks some robust features out of XTRADB which is a major improvement of INNODB engine. Trust me. what you are looking for in feature sets is spread out between those engine. Think al stop now before i go on and on.

 

From: Rad! [mailto:conradakunga@gmail.com]
Sent: Thursday, June 11, 2009 12:15 PM
To: steve@sobbayi.com; Skunkworks forum
Subject: Re: [Skunkworks] MySQL on Windows

I am only to happy to respond to your vaguely condescending email.

I have a project that stores maps in a database and generates a map depending on various criteria. For that native shapefile support in a database is not bloat. It has saved me days of wrestling with issues like serlializing and deserializing shapefiles for storage and display

For another project I have some legacy data (unnormalized) in the database that I need to process prior to display. (For political reasons normalizing it is not possible) Most database (except maybe Oracle) have very rudimentary regular expression support. .NET has a very good regular expression engine and so I wrote some functions in C# to expose that. CLR support is not bloat.

Reporting using datetimes is very cumbersome because of the time element. You invariably have to find some way to remove the time when querying data stored as datetimes. Same problem when you're only interested in the time. So separate types is not bloat.

You will find use for a timezone aware datetime when you develop a scheduling application that allows people to set up meetings. Just try doing that using normal datetimes. 3 o'clock in Nairobi is not 3 o'clock in New York.

And so on. Like I said, it depends on the projects you are working on. If your domain is sacco software then I agree you'll never get to use most of these features,unless its datetime.

As for the features working -- if you are replicating a terabyte of data, something is wrong with your design. There are better ways t do it (mirroring, log shipping, etc).

As for that old argument of features=bloat all I can say is it depends on you. One man's candy is another man's bread and butter. Personally I prefer a Swiss army knife to a butter knife. Either way you can still butter bread. I've stopped trying to wrap my brains around the argument that lack of features is a good thing.

By the way, your point of storage engines is deceptive. (For the record I have some projects that are using MySQL 5). The problem with the multiplicity of storate engines is that they all offer features that the others lack. What if I wanted an engine that had soe features of InnoDB and other features from ISAM?

By the way, please notice that NOWHERE have i said SQL Server is better than MySQL, or vice versa. I just said what I happened to find worked very well for me. I dare say more people would benefit from this discussion if we kept it from degenerating into 'my daddy can beat your daddy' if you outlined what about MySQL makes it your database of choice.


On Thu, Jun 11, 2009 at 7:57 AM, Steve Obbayi <steve@sobbayi.com> wrote:
 
I was going to put my foot down on this until i read this line
 
"Depending on your ability to make use said features, your mileage may vary"
 
There two things every developer should look at when features are listed in a Software Product.
 
1. Are those features really practical and applicable in ones use case - its like telling me your car can move at 300 mph and drag and elephant accros sahara on a gallon of gas - when am i ever going to get an opportunity to do that?
 
2. Do those features actually work as well as supposedly stated by the vendor. I this case when i say work i really mean something like this... am i gonna be able to replicate one terrabyte of data halfway accross earth and it takes me 36hrs especiall if am using one of SQLservers relication such as snap shot. might as well do an SQL dump of the data and fedex it to the remote location and have it imported back in. nuff said.
 
Now in many cases without going into details, SQL Server (in general) has come short of expectations. Just a quick comment. Packing features into a product causes it t become bloated and thats why we have what we call plugins. A good product has all the necessary stuff one needs and the addition candy supplied as a pluggin. Now with RDMS like MYSQL it has been deliberately stripped off some of the features to make it as robust as it is today... Wait. here's the catch. some of the features have also simply been moved into various storage engines so the developer has the ability to choose what engne and features they need.
 
I'll stop there
 
 
Steve Obbayi,