What are the major differences between databases?

Question

I\'m not fanatic on any database but I wish to see differences between vendors.

For instance, I use mostly Oracle and I see that others (MySQL, SQL Server, PostgreSQL, .

Answer 1

Differences depend on your intent--unless you really want just an exhaustive laundry list. In other words, it appears that you really mean to ask about significant differences, and significance varies by intent.

I suggest that most people typically find several specific things to be significant:

• performance
• compatibility
• portability
• advanced features
• ease of use
• cost

The relative significance of these database characteristics seems to vary primarily based on whether one's intent resides within programming in-the-large or in-the-small. Since I mostly work in the world of programming in-the-large, I will speak from there. When I work (typically on my own projects) in the world of programming in-the-small, I usually still lean towards my decisions for the world of in-the-large since I find it easy enough and I prefer to save myself from the headaches of changing my mind later when my project grows up. I have noticed that many open-source projects suffer huge, sometimes fatal, growth pains when their following forces them to cross the threshold from in-the-small to in-the-large.

My first concern is that I must always be able to change my mind about my choice of database vendor and product, so compatibility is king and portability is queen. With that in mind, I strongly prefer to treat the database as a storage medium only, so I avoid putting any code into the database and I avoid any features that are not relevant to storage or are specific to a vendor or product. For a RDBMS, compatibility primarily means ANSI SQL standard compliance, so I immediately reject any product that is not reasonably compliant. Since I work in the worlds of Linux, Unix, and Windows, portability means availability on all those platforms.

My code belongs together and in the best environment for it--not separated into the crippled environment of a database engine; another aspect of what it means to treat the database as merely a storage medium. Therefore, coding features have limited relevance to me. On very rare occasion, I will create code in the database for a trigger or some convenient functions, so I expect ANSI SQL compliance for basic capabilities and that is all.

I usually have a lot of data, so performance is important and I am willing to trade off some ease-of-use to get it. I don't mind a heavy database installation, or a complex database structure, if I have some basic tools to facilitate and automate the process. That means that I should be able to script the installation of the database engine (binaries) as well as my database structure and data. Being FORCED to use a GUI, as the only option, for important database tasks is unacceptable.

Sometimes, usually in the name of performance, I find it necessary to use a specific feature that drives me to a particular vendor or even a particular product. I do my best to isolate that dependency and to retain my option to switch to another vendor or product, without sacrificing the benefit from that special feature. I might even build an entire system around the special value derived from such a vendor-specific or product-specific feature, but only by explicitly accepting the cost of having done so. The cost of limiting one's options seems to outweigh every other form of cost.

Obviously, the price to purchase the database engine is a cost, but so is the loss of freedom in how to use it. Therefore, I value open-source products VERY highly.

Finally, I am often constrained by the decisions of others, such as my clients. Therefore, I further attempt to be flexible in accommodating choices that I would not make myself.

Given all that, my primary preference for a database engine is SQLite, because its compatibility, portability, and freedom of use outshine all others.

Second, I love Oracle, and I prefer it for programming in-the-large. It is not cheap, but it can do whatever I might need with the best mix of compatibility, portability, performance, and features.

Third, I use Microsoft SQL Server when my clients require it. I maintain skill and compatibility with it because it is too dominant in the market to ignore. It might even have a special feature that I need someday, although I have yet to encounter that situation.

I avoid MySQL because of its lack of compatibility, but I have often supported it as someone else's choice. I considered it for my primary preference, but my in-depth review of its characteristics made it clear that one cannot readily shift a code base between it and any ANSI-SQL-compliant RDBMS. For me, that is completely unacceptable.

By the way, my target for such a shift to a different database engine is a few minutes up to about a week (forty hours). Since I wrap my database access with a compatibility layer, I find that I can usually switch database engines within a few hours at most. Often, my applications are able to support multiple database engines simultaneously (via a simple configuration change at startup).

Best wishes.