SQL noSQL

SQL Boy Q Oct 26, 2018 Tags: Database Backend

I’ve been working nearly exclusively with NoSQL databases because they’re a lot different than traditional SQL databases, and how you approach them feels very foreign to me to an uncomfortable degree. One of the things that I’m still wrapping my head around is associations and the fact that you don’t always necessarily make a new “table” for them. To give a more concrete example, I’m working on a Dribbble clone, In a traditional SQL database I would approach creating the user table as the following:

The user table itself would consist of email, password for one table and the second table would be the “profile” table which would consist of the more personal information such as: location, twitter handle, background photo, profile photo, website, list of skills. A profile table belongs to a user, and a user has one profile (that is dependent on the user, thus if the user deletes her/his account the profile goes with it). With NoSQL databases, it’s not necessary to create another table to handle this association and can be embedded within the user document without much worry. Embedding the profile is the best approach for the profile because the profile is definite in the number of objects in it (create a separate document if you expect the size of said document to grow example being: storing user all a user’s comments).

It’s definitely taken some time to really wrap my head around this, and even on this I’ve found myself questioning “do I need to even embed” I find myself asking this due to the added complexity that comes with embedding and trying to both populate and query against embedded data. If you take a my commits for (Chirpper)[https://github.com/diope/chirpper) you’ll see I go back and forth between embedding the profile and keeping it on the same depth as the rest of the user document.

It’s an interesting challenge working with NoSQL, in some ways it feels familiar to SQL databases (mostly in how you query data, it’s quite similar to most SQL ORMs), unfortunately I miss the power that comes with knowing SQL and being able to use that to be more nuanced (and performance minded) if necessary. I do not look forward to learning normalization techniques for NoSQL DB given how long it’s taken me to really get used to SQL databases techniques. That and I still find myself thinking of everything as SQL associations and joins.

Honestly I prefer SQL databases (postgreSQL is bae!) but I do appreciate a few things about NoSQLs mostly the fact I can edit data much quicker, no migrations needed, you can even directly edit documents on the fly which in some cases makes troubleshooting easier.