Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

General Discussion

Steven Fullerton
Steven Fullerton
6,712 Points

What type of database should i Use?

Im trying to create a web-app which allows users to sort through and create cards, functioning in a similar way to how 8tracks.com works, that is, objects which contain data, tags and an image that are searchable sortable and new objects can be created by the user.

I have looked at some CMS's but they seem to focus on page/post creation rather than objects.

Does anyone have any suggestions on systems or framework that may be useful to look at? I am a front-end designer and have little knowledge of databases etc.

5 Answers

Adam Sommer
Adam Sommer
62,470 Points

Might look into a NoSQL solution like MongoDB or CouchDB. They let you store documents in Json. CouchDB is pretty easy to get started with.

James Barnett
James Barnett
39,199 Points

MySQL & Postgres are both great choices, any relational database will work well. I would not recommend someone new to databases use a NoSQL database. CouchDB (and MongoDB) solve some very particular problems, such as for a website that has 5 million daily views.

James Barnett
James Barnett
39,199 Points

Here's an interesting take on the pro's and con's of scalability of NoSQL vs relational databases.


First learn SQL and the relational paradigm.

SQL represents 40 years of experience designing general data stores that work for the widest set of applications. SQL databases solve many very hard problems which you are probably not aware of.

If you jump into NoSQL first you will be implementing SQL features in your application code, and doing a shitty job of it because you have experience with data stores that actually solve these problems well.

The reason for the existence of so many NoSQL databases is the rise of web applications and the need to scale massively. However the majority of apps will never need to scale beyond a single well-tuned database server anyway. By the time they do you will have had problems to solve regardless of what data store you used.

The advantage of SQL is that it's a fantastic hedge on the evolution of your data usage patterns because it is designed to support ad-hoc queries well, and the schema prevents bad application code from trusting your data into chaos at the first occurrence of a small bug.

Realistically if you knew you had to build an app for 5 million daily users, and you knew exactly what it was going to do, then an SQL database very well might be the wrong choice.

But in the real world you have a long road ahead before you hit that scale, and you'll have real data to determine what kind of alternate data stores can best handle your load. Personally I'm a huge fan of redis, and its ability to scrape bottlenecks off a MySQL database in a piecemeal fashion.

Source: https://news.ycombinator.com/item?id=1636551

Adam Sommer
Adam Sommer
62,470 Points

I agree James, SQL is great for a lot of things. I suggested a possible NoSQL solution because it is simpler to learn how to send a Json POST or PUT to a server than it is to learn an entire new language like SQL.

Also, from my experience administering CouchDB and Redis is a lot simpler than administering MySQL and PostgreSQL. Just because NoSQL databases can scale to millions doesn't mean they have to ;-).

Adam Sommer
Adam Sommer
62,470 Points

Heh, just read the first comment in the link you shared:


NoSQL isn't just about scale. Sometimes, modeling data relationally is a real bitch, and a document store makes more sense.

That's pretty much my thought when considering the database needs for an application. SQL is good though, I don't mean to hate ;-).

Party On!