Wednesday, June 25, 2008

An embedded or a non-embedded ?

For those who want to run light quick and portable apps, embedded DBs are the way to go. But what if you have an enterprise web application that would be used by all the departments in the an enterprise company and you have a web site to hook to the DB too and your company is a very important financial institution ? Would you use an embedded Db or a solid network based , non - embedded DB ? I would rather throw aside the embedded ones if I need a solid , fault tolerant database ... and of all, they should be written in non VM based languages like Java.

So let's touch on why I think embedded aren't going to be a good option in my view. Embedded are mostly optimized for the portable stuff... small and sleek... but the compensation for some small stuff is mostly ... the ability to tolerant huge traffic ... lots of faults and errors occuring. What do you really expect for something made so small and used for embedded applications ?

I would prefer to go for those solid MySQL or Postgres servers which are dedicated servers with networking capabilites. Codes are not needed to be withold to make it small and light ... instead... codes are made in these stable database servers , to withstand enormous amounts of faults and traffic.

Why do I say that it's not recommended to use VM based languages to create enterprise databases ? Simply because, before the codes upon execution , have to pass through the VM tier before actually executing. If you use a code that directly 'speaks' native language, you bypass the troublesome VM tier. It would be faster indeed.

So if you want a database to handle real enterprise stuff, I would prefer to use a dedicated , non-embedded database and if better.

No comments: