Building a NoSQL Database

I have an undergrad degree in Computer Science and what I learned while I was in school about databases mainly concerned relation-based databases. I mean, sure, a teacher might mention that other types of databases exist, like Object-oriented…and honestly if I were to speak from my academic experience, that’s the only other example of database type I could come up with.RDBMSvsNoSQLNevertheless, I was assured that there’s no real need to study any other type of database, seeing as so many big players have put their money in RDBMS. And, as far as my professional career is concerned, they were right.However, when I started working on mobile apps in my free time, I opted to go with Parse as my solution for data storing. And Parse operates on a NoSQL database and that was fine, in the beginning, because I didn’t have to do much of anything except query the database in the beginning and Parse made that exceedingly easy. But since all good things must come to an end, my friend and I have reached that point in our development process in which we have to work with a database that stores more than usernames and passwords. And here comes the pickle: we need a database structure that will support our need to store details about a product in one class and compare those details with flags we store in another class.My knee-jerk response was to suggest a many-to-many relationship table, like the ones I used to create to normalize the database given from countless classroom exercises. But then, the reality of using a NoSQL database hit me. NoSQL aren’t databases constructed to have relationships between tables, they are created to store data in such a way that optimizes queries run against them. So we went online searching for an answer and here’s what we found.

  1. Can’t be done.

The overwhelming results we came across was that storing data based on a relationship between 2 data entities cannot be done in NoSQL. Furthermore, all the hype about NoSQL is fabricated, it has no actual or practical usage outside hipster-filled development companies, long live RDBMS!!!

  1. Maybe…but you’ll need a lot of redundant data and complicated back-end jobs

Seeing as weren’t really in the position to give up either our application or working with Parse, we forged on and found some people who were more inclined to offer useful advice. And, mostly, the advice boiled down to respecting what NoSQL databases are all about and constructing our classes to respond to our query needs, even if that meant we’d end up with redundant data all over the place. Unfortunately, this also means that you’re going to have to periodically run some maintenance jobs on your database in order to make sure that changes that appear in one place are spread throughout your database. Still, it’s an option.

  1. Long live Parse!

Finally, we arrived at this blog post by Parse and all our problems were solved. Now, I know it may seem like it took us a lot to arrive at the solution proposed by our own database provider, but I assure you that the entire research process took about half an hour. Anyway, what Parse is proposing is a simple primitive object called PFRelation that helps you maintain relationship information between two objects in a way similar to associative tables in the relation database model.However, if you’re not running your database with Parse, there are some options available to you as well, although I couldn’t tell you too much about them. Other options we came across but didn’t really look into were Google’s, Kinvey’s and FatFractal who actually propose a solution similar to Parse’s. They created GRABBAG, a set of references to any number of other objects that is maintained through backend code rather than being stored in the database. Check out their solution here.

Published by


I may be late due to who I am as a person