Friday, December 08, 2006

Selecting a Database

When people are comparing databases and trying to select the correct one for their application, it is a very complex and confusing process. There are many factors, price being not the least of these. Some would opt for a closed-source product because of the extra bells and whistles it offers. I have to say that some of these extra features may represent security risks, or simply a database trying to take on functionality better performed at the application layer. There is a certain argument to have all of your business logic embedded in the database as it certainly eases the burden on the application programmers. But it can allow them to become sloppy, or to allow the database to be exposed directly to the users without even an application layer to protect it, counting on the database to protect itself. In some cases this comes at a price, sacrificing speed for security, when some fairly simple application coding could have implemented the same security and retained the speed. Granted some things are better done in stored procedures than application logic, and it's worth running some tests to see which is better, or considering moving the logic to the database if it is performing poorly in the application.

Price, too is a consideration. With open source, you can test the functionality without an initial investment before opting for a support package. Then, when the decision is made to purchase support, MySQL sweetens the deal by offering the Enterprise package, with some extra functionality just for the paying customer. True, it is new, and has some issues to be worked out, but it is a marvellous concept, and I am curious to see some indication of how well it is selling. As I have stated before, perceived value is an important aspect to some people, the 'bang for the buck' principle, and this new offering caters to that.

Sometimes it is a mindset issue, and I have to say I have been guilty of this at times. It is very easy to move into a new situation and recommend the familiar tools that one is familiar with, even if this means a capital outlay for the new employer. I have done this, and also had this done to me by others, so I can't be too hard on them. Open source requires an open mind in a lot of ways. I see many ingenious solutions to problems. I also see these rejected at times by those of narrow perspective continuing to try to develop solutions in this new environment using guidelines and experience drawn from elsewhere.

Not that experience isn't valuable, but the spirit of innovation must prevail, and a willingness to accept change. Also sometimes one must consider that perhaps the familiar closed-source product has rather bent the standard and changed the rules, so that suddenly finding an environment where these rules are enforced, and with increasing strictness, can be a shock to some. Some complain of this behavior, calling it wrong if familiar code won't execute because it took advantage of an extension previously available.

Sometimes this failure leads to a decision to return to the closed-source world, despite all the good advice on how to adapt.

3 Comments:

Anonymous Anonymous said...

You should check out EnterpriseDB (www.enterprisedb.com) if you would like to see an enterprise-class database meant for concurrency and OLTP. Recent benchmarks show MySQL has real issues when any sort of meaningful traffic is thrown at it.

8:13 AM, December 11, 2006  
Blogger Sheeri said...

tac89611 -- if "issues" means run smoothly, then yes, our company has issues with our very meaningful traffic (average load 3,000 queries per second on OLTP servers with 1/3 of them being writes).

Do you have any sources, or are you just taking one or 2 recent benchmarks?

12:47 PM, December 11, 2006  
Blogger Sheeri said...

http://www.tmcnet.com/news/2006/12/06/2147617.htm

no meaningful traffic there.....

12:52 PM, December 11, 2006  

Post a Comment

Links to this post:

Create a Link

<< Home