What are the factors in choosing a specific Database Management System? [closed]_问答_开发者

Closed. This question needs to be more focused. It is not currently accepting answers.

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question 开发者_Python百科

Why are there so many Database management systems? I am not an DB expert and I've never thought about using another Database other than mySQL.

Programming languages offer different paradigms, so it makes sense to choose a specific language for your purpose.

Question

What are the factors in choosing a specific Database management system ?

Different Strokes for Different Folks:

The .NET people like the homogeneous stack that Microsoft SQL Server provides.
Oracle is the 'Please use in Enterprise Applications only' DBMS.
MySQL and PostgreSQL are used by the Open-Source crowd.
SQLite is great for an embedded DBMS.
Microsoft Access is great for a One-Person Microsoft Office Integrated Database (or, for people that don't know any better)

I know next to nothing about non-relational DBMSs: NoSQL, MongoDB, db4o, CouchDB, BigTable. I'd recommend a different question to address those, since their aims are different than traditional RDBMSs.

DBMS are around for many many years and very important for the IT infrastructure in the past, nowerdays and for the future. So a lot of people tried to get into the business. There are a lot of office suites, internt browsers, etc, etc.

What are factors to choose a specific DB management system ?

Licensing
Platform
Performance
Supported programming language
etc, etc

If the paradigms are the same, it's also a market sharing issue.. (Has it been skipped?!?) Otherwise, Peter's answer is considerable.

There's a noticable absence of e.g. column-oriented (LucidDB), platform independent (derby), in-memory (hsqldb, although derby fits here as well) and probably other databases, as classified by their key properties.

"This answer doesn't really answer 'why', it just answers 'who'."

True, but I guess the answer to 'why' might be that there have been so many 'who' 's who all thought they could do it "better than the others".

With "better" having the significance of a fill-in-the-gaps that the particular 'who' chose to pick on :

nearly watertight guarantee of read success through MVCC locking, as opposed to more traditional two-phase locking.
no fee, as opposed to million-dollar fees
easy interfacing with language XYZ, which the others don't have
...

My personal pet issue is support for CREATE ASSERTION. It's been in the SQL standard since 1992, and none of the big elephants know how to support it. I do.

For the most part, if you are writing for the RDBMS/SQLish market, the number one question you should probably ask is, "What do I already know about? What does my staff know about?" If you have an answer for that, then you should probably pick that SQL engine first. My inner database geek cringes at this answer, but the truth is that unless your developers are among the tiny fraction that really get relational databases anyway, you're going to use the same deep ruts of standard database mistakes as everyone else, and the main question is going to be whether you can get your system to go fast enough.

This is probably true if you've swallowed a pitcher of the NoSQL beverage of choice as well, since there too you have to pick the thing you understand.

If you are already in a position to understand all these differences, however, then you will understand that the answer is "it depends". The usual four dimensions come down to these: execution speed for a given workload profile (this is a matter of whether the database is excellent at the particular kind of problem: some are faster for lookup, for instance, where others are better under high concurrency writing); SQL conformance in the target areas (e.g. Oracle has funny -- i.e. wrong -- NULL handling, MySQL is all over the map, Postgres wraps unquoted identifiers to lower case); money cost both immediately and over the long haul (include hardware requirements, costs of hiring people, licenses); and maybe features you want (if you want Oracle's RAC, you have to buy Oracle).

Database systems offer different paradigms too. For instance, MySQL or MSSQL are relational, while db4o is object-oriented, and MongoDB is document-oriented.