DBMS stands for database management system (abbr ftw!). Simply put it’s a way for users to interact with data. A common misconception when learning about DBMS is referring to them as the database itself. It’s actually an intermediary between the user, data, and other applications to capture and analyze data sets. During your journey as a developer you will likely reach a moment where you’ll need to ask yourself “self: which DBMS should I use?” My goal is to shine some light on the pro’s and cons of some popular ones that are out there for you to better reach that conclusion on your own.

Three examples of commonly used DBMS in today’s development world are SQLite, MySQL, and MongoDB.

SQLite

SQLite is a neat little RDBMS released in 2000. A unique aspect of SQLite is it is embedded in the application running SQL as opposed to a client server database engine. This means it is tightly integrated in the application and makes calls to files that contain the data locally as opposed to a server. That alone makes SQLite very compact and portable for basic querying analysis, but at a cost.

Because of how portable this DBMS is it’s ability to handle multi-user applications are limited. If you’re looking for scalable DBMS’s that can handle multiple users or high writing volume this one is likely not a good fit.

MySQL

MySQL is ranked #2 in terms popularity just behind Oracle. As you might have assumed, MySQL is built to handle larger volumes of data and users. It comes with many of the standard SQL features one would expect when using a RDBMS and also comes with a more advanced built-in security interface.

Limitations when considering MySQL is it’s inflexible nature at using storage engines other than the default InnoDB. You give up some of the standard SQL functionality when using other databases “including foreign key references and check constraints.”

The general consensus seems that MySQL’s ease of use through open-sourced tools has helped it reach the level of popularity it has gained today.

A few companies currently utilizing MySQL include sites such as Google, Facebook, Twitter, Flickr, and YouTube.

MongoDB

The key difference that sets the other reviewed DBMS from Mongo is it is a NoSQL document-oriented database program (now that’s a mouthful!). What does that mean exactly? Well let’s break it down:

  • NoSQL - Does not imply what you might think. The “No” actually stands for Not Only. In other words SQL isn’t the only language accepted to write queries. All that being said, Mongo does not support SQL when running queries.

  • Document-oriented database implies that, unlike it’s sibling relational databases (table based), all of our data can be stored in one single instance in the database. This allows the task of mapping to be quite flexible. Here’s a great article comparing document oriented databses vs. relational oriented databases.

Additionally, the syntax of writing Mongo queries are quite different from SQL and seem very method like.

A standard SQL query such as…

SELECT * FROM inventory WHERE status = "D"

Would be re-written as…

db.inventory.find( { status: "D" } )

Mongo also supports a vast majority of popular langues out there…

MongoDBLanguages

Some downsides to this language (which is entirely subjective): the lack of structure makes it difficult to standardize for users. There also lacks a good security configuration which resulted in DB’s being stolen and held for ransom.

All-in-all it’s really up to you and the application you’re trying to build. In my opinion it seems best to start small and work your way up as needed, but don’t wait too long to upgrade or integrating a new system to fit your needs could prove to be quite difficult.

Here’s a fun mapping of Facebook’s class design. Enjoy!

FacebookSchema

Questions or comments? Feel free to shoot me an email (click the link below).

source