This course has been updated! We now recommend you take the Full Stack for Front-End Engineers, v3 course.

Check out a free preview of the full Full Stack for Front-Ends Part 2 course:
The "Database Types" Lesson is part of the full, Full Stack for Front-Ends Part 2 course featured in this preview video. Here's what you'd learn in this lesson:

Jem explores the differences between relational and non-relational databases, and how to pick your DB type based on usage and requirements.

Get Unlimited Access Now

Transcript from the "Database Types" Lesson

>> Jem Young: Now we're moving onto databases and this is the final portion of the course. Last two sections, so you're all good, you made it, you've got a modern website running like a fine tuned website. Yeah, it's doing well right now. So let's talk about databases. As one of my favorite professors in college once said, as your job, mostly what it boils down to is writing something into a database and getting something back.

[00:00:29] And when you think about web applications, that's almost all exactly what you're doing. You're putting stuff in and you're taking stuff out, that's it. You may do some data lunging on the side like parse it, do whatever you want. But at the core you're putting something in the database, you're getting something out, that's it.

[00:00:44] That's why I'm putting this section about databases as part of full stack because at some point you're gonna have to run a database for something. So the two types of databases that we mainly need to concern ourselves about are relational and non-relational databases. Now, someone tell me the difference between a relational and non-relational.

>> Speaker 2: Schemeless versus documents, or table versus documents.
>> Jem Young: That's exactly right. Schemeless versus documents, or table versus documents. Essentially a relational database means the data relates to other data in some way. So you can index these things much easier, you run SQL on relational databases. Non-relational database, it's better to think of it as a document store key value store.

[00:01:27] You can put in any sort of data you want, you don't have to format it, you can just dump it into the database as fast as possible. Some examples of non-relational database Redis which is a key value store, it's very very fast. Cassandra, Mongo DB is a very popular one for document store they just had an IPO doing pretty well so I hear.

[00:01:47] Relational database you probably heard cuz that's the one running SQL, Structured Query Language. MySQL, Postgre, SQL Server very popular servers, very popular language because before, if you think about the days before SQL, you have data. How do you get it back out? And it's a hard problem, it's a hard problem.

[00:02:09] Yes, where I have data that I wanna store,, what format do I put it in? I can't just dump it in there, I have to have some sort of structure to it. And that's where the structure query language comes in. The down side of that is, that I have to formulate my data in a very specific way to fit into my database.

[00:02:26] So you have SQL and you have to process all these things versus something like Redis which is just a key value store. Doesn't care about the structure, you've put it in with the key and you've put it in with the value, whatever you want to be, and it's just fast.

[00:02:40] The difference is SQL tends to be a little bit faster if you querying thing. So if I wanna say, how many users are logged into right now, I use SQL for that. Because I can make a query that give me that exact data versus a non-relational database.

[00:02:54] I'd have to parse all this data, extract it out, modify that, I'd essentially have to map reduce. I'd have to map that data reduce it down to the value that I want. That's the difference between a relational and non-relational database. So before everybody wants to be like, I wanNA use couch DB or I wanna use Mongo or I wanna use all of these things which are heap and cool and fast understand what kind of data you're gonna store.

[00:03:17] How's the data gonna look in the future? And how fast do you want it to be? Non-relational data tends to be much faster for inserting, because there's no schema, you don't have to process any data. You just throw it in there, essentially get a bucket and throw it in there.

[00:03:31] It's a bit more complicated than that, but that's a good way of thinking about it. And then getting data out is very fast too. And everyone's like use Mongo, use Redis, but if you wanna actually run analytics of some sort, eventually you wanna infer user behavior. You wanna understand what's happening at the core structural query language is probably the way they go.

[00:03:49] Make sense, any questions on database? That was a lot, I got, been very generous on it. Yes.
>> Speaker 3: Is Firebase considered database?
>> Jem Young: Firebase is, I believe it is an API, API as a service. I'm not that familiar with it, but I believe it's a way of setting up API's on their server and having it return things.

[00:04:12] Does that help? Yeah.
>> Speaker 4: It has a NoSQL database part of it.
>> Jem Young: Okay.
>> Speaker 4: It's like proprietary.
>> Jem Young: Okay so it does have a database built into it. That's pretty cool, they got bought by Facebook, right? I don't actually remember, Google? Okay, yeah I've seen some Firebase examples on Google sites.

[00:04:34] But that at a very, very, very high level is databases. Now I say very high level because there are entire fields of computer science that just have their databases. Their entire career is that all you do is database administration because it's very very hard. If you're at that level, you probably wouldn't be in this class.

[00:04:51] Or maybe it's forgetting, so congratulations, you're off on a wonderful journey. But essentially when you're trying to pick is you're starting a brand new server, you're trying to pick the type of database, keep these things in mind about relational versus non-relational. Cuz it's really tempting to use a non-relational database cuz it takes less work, less queries to get it in, but you may pay for that later on.