Choosing a Database for OOP Projects. We Went with MongoDB, but Should You?
Intro
A few years ago we were choosing a database for our OOP projects. SQL databases didn’t seem to work with OOP, so we looked around.
Here’s what we needed:
- Good OOP support (polymorphism, composition, inheritance, delegation, etc.);
- Cloud independent options;
- Good horizontal scaling;
- A tried and true solution.
With our experience, we’ll help you choose a database that’s right for you. We went with MongoDB, but you may need a different one. Let’s find that out.
Types Of Databases
The chances are, your OOP application needs a database. But with so many options out there, it’s difficult to make a choice. Let’s give it a try anyway.
Here are the main database types used today:
SQL
- Relational
NoSQL
- Document-oriented
- Graph databases
- Key-value databases
- Mixed databases
Relational Databases & SQL
For many years relational databases were the most popular ones. Lots of small businesses, corporations, and non-profits still use them today.
Such databases are based on the relational data model, which organizes data into tables with rows and columns.
Relational databases use SQL (Structured Query Language) to manage and retrieve data. SQL is a declarative language, which means that users can describe what they want the database to do. After that, the database management system will determine how to carry out those instructions. SQL uses commands such as SELECT, INSERT, UPDATE, and DELETE to perform operations on the data stored in a database.
OOP & Relational Databases don’t go well together:
Object-Oriented Vs Relational Approaches
At the same time, Object Oriented Programming languages (C++, C#, Java) were developed and gained popularity.
OOP is a way of programming that organizes data and behavior into objects. This approach allows for a more modular and flexible design. With it, developers can easily adapt to changing requirements.
OOP and relational databases don’t fit very well. In OOP, objects are connected to the high-level goals of the application. Meanwhile, relational databases simply deal with data inside tables.
This leads to issues with inheritance, polymorphism, or encapsulation – the core features of OOP. Relational databases don’t support these out of the box.
Still, for a while apps written with OOP continued using relational databases, because they didn’t have many alternatives.
Workarounds: Table Inheritance & ORM Frameworks
How Object Relational Mapping (ORM) Works
Many relational databases have workarounds for OOP. For example, PostgreSQL tackles the inheritance issues with table inheritance. Yet for the most part, it’s really difficult to implement object hierarchy into relational databases.
The best workaround today is to use an ORM framework. With ORM, objects are mapped to database tables, and vice versa. There are many advantages to this approach:
- You can go on working with objects in your code;
- You don’t have to write SQL queries;
- Transactions become much easier.
But this is still not a perfect solution. For example, let’s take a look at Java with an ORM framework called Hibernate:
It creates its own SQL queries, which are not perfect or optimized. Sure, you can track slow queries and optimize them manually, but it will take your time. If you need high performance, ORM is not for you.
You’ll find more or less the same issues with other ORM frameworks and OOP languages
We decided to give NoSQL databases a try. We wanted to check their pros and cons. And who knows, maybe we didn’t really need SQL?
Choosing A NoSQL Database
Relational databases didn’t work well with us even with ORM-frameworks, so we looked for a good NoSQL database.
Here’s what we needed out of our NoSQL database:
- A cloud independent solution, so we could host data on our own servers;
- Good horizontal scaling (scale out). We wanted to add notes like new computers or servers to the system whenever we needed;
- A tried and true solution with a large community.
When you pick a database for your app, you need to consider lots of factors. Do you need to store cache, logs, or entities? If you purchase a cloud database, how much will the hosting be? If you build a self-hosted database, how expensive will the maintenance be? And so on.
In any case, it’s really important to be picky about your database. If you choose the wrong one, it may set back the growth of your project.
We put together a list of databases, but most options quickly fell off:
- Couchbase had a pretty small community with few contributors. On top of that, it didn’t support the cloud computing services we needed. It only supported AWS and Azure, while we needed IBM or Google Cloud;
- OrientDB, just as Couchbase, only supported AWS and Azure. It also had too small of a community;
- CouchDB turned out to be smaller than MongoDB, and we also had issues with horizontal scaling;
- Elasticsearch was optimized for searching and indexing unstructured data like logs and metrics. But It’s not so good for persistent data. Especially when strong transactional guarantees or complex joins between multiple tables are important. Also, Elasticsearch wasn’t as stable a few years ago when we were looking for a database.
We were left with MongoDB and Cassandra. Turns out, both are great databases, but let’s find out which one can suit you best.
MongoDB Vs Cassandra
MongoDB Vs Cassandra
Choose Cassandra when:
- You need to handle massive amounts of data (over 10 TB). It’s perfect if you need high write and read throughput with low latency;
- Your application needs to be highly available and fault-tolerant;
- You need linear scalability to handle growth in data and traffic.
Choose MongoDB when:
- You require a flexible and scalable document data model with dynamic schemas;
- Your application needs to be easily scalable horizontally without needing to manage complex data partitioning;
- Your application needs to support rich queries and indexes.
We went with MongoDB because we knew that our data system would be changed often. We would have complex queries and aggregation. Transactions in MongoDB were a nice bonus, although we hardly use them now. Our database wasn’t very huge, and it didn’t have to be quick as a flash, so we weren’t put off by the speed.
In our experience, MongoDB is perfect for small and mid-size applications. Our work became much simpler compared to the times of SQL databases. All the features that we needed were available out of the box: complex search, complex aggregation, a huge set of indexes, and horizontal scaling. Now we don’t have to waste time developing and maintaining these features.
As for the downside, doing system administration was not as simple nor straightforward as with SQL databases.
In The Nutshell
Overall, both Mongo and Cassandra can save your company lots of time and money when you use them right. If your cloud provider supports the databases, give them a try for OOP development. They won’t disappoint.
If you’re looking to design a database or hire developers experienced with MongoDB or Cassandra, feel free to reach out. We’ve been working with the databases for 5+ years, and most of our developers are Middle and Senior tier. We’ll be happy to help.
