Inner joins are our tool of choice if we’re looking for a specific set of data that only matches the parameters we identify in our query.įor example, say we’re looking for a subset of data that shows only users with orders. The most common and easiest join table syntax to understand is the inner join. Each Order also has a unique, randomly-generated number (think order confirmation number), and an order total, which is stored as a Ruby BigDecimal object. Each User instance has a first_name and a last_name (and realistically speaking, probably a bunch of other attributes…but let’s keep it simple for now).Įach Order object belongs_to a User, which means it has a user_id column to store the foreign key from the Users table. We’ll be working with the same two tables: a Users table, and an Orders table. Anyways, here’s what our databases look like: Since we don’t have any real users yet, we can just populate our database with some fake, super fun seed data.ĭisclaimer: I may or may not have gotten carried away when making the seed data. ![]() Know Thy Dataīefore we get too deep into join syntax, let’s take a look at our data! We’ll stick with the schema from our eCommerce bookstore application. Let’s explore the differences between inner joins, left outer joins, and right outer joins. There are seven different types of join tables, but there are three in particular that I’ve encountered time and again. ![]() Join tables are how we get specific information from two different datasets (or two different database tables). Most of the time, the data in a single table by itself isn’t super useful when it’s combined with another database’s information, however, then things really get cooking. No matter the size of your application, you’re probably going to have at least a few tables, and usually many more. Depending on what you query the database for, different values can be returned. Join tables are used to combine two sets of data from two different tables. So, what should we get to know about them? Well, the scariest part, of course: join tables. But, you shouldn’t! And I hope that, after reading this post, you won’t! Because databases are beautiful (that should be on a t-shirt somewhere), and you just have to get to know them a little bit. Between database migrations, which we unpacked last week, and writing SQL queries that actually do what you want them to do, it’s really easy to just throw your hands up in the air and give up completely. I think that a large part of what makes databases hard to understand is the sheer amount of things you can do with the data it contains. ![]() Databases are hard! They’re beautiful and super fun once you understand how to manipulate them, but until you get to that point, they’re pretty much just hard. While I wholeheartedly admit that I belong to the former camp of believers, I can understand why someone would subscribe to the latter group. There are those people who love them, and there are those people who just hate them. When it comes to databases, there are generally two schools of thought. This blog post is part of a series on databases.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |