In a recent post to his site Jonathan Reinink has written up a guide to using dynamic (Eloquent) relationships in Laravel applications by making use of subquery functionality. In it, he shows how to make use of the selectSub method to select additional information in a single query versus having the overhead of custom, hard-coded relationships.

When building web apps that interact with a database, I always have two goals in mind: keep database queries to a minimum [and] keep memory usage to a minimum. These goals can have a drastic impact on the performance of your app.

Developers are typically pretty good at the first goal. We're aware of N+1 style problems, and use techniques like eager-loading to limit database queries. However, we're not always the best at the second goalkeeping memory usage down. In fact, we sometimes do more harm than good trying to reduce database queries at the expense of memory usage.

He starts off with the challenge he's trying to solve: gathering login information for users in a performant way. He includes the schema for the users and logins table and shows the code of how a normal relationship select might look to get login information for each user (creating an N+1 issue).

To help solve the issue, they try caching the last login information but realize they can do better - this is where subqueries come in. They provide an example of using the selectSub method to get the login information, mapping it to a macro for easier use and defining scopes. Finally, the tutorial shows how to use this method to select information via dynamic relationships. It also talks about lazy-loading issues and if the same thing could be accomplished with a "has one" relationship.

Tim MacDonald has a new post to his site sharing methods that the Laravel Eloquent users (either in the framework or outside of it) can use to load in the counts of relationships without having to fetch the entire relationship data set.

It is often useful to show the number of related models a given instance has, but not actually need any specific information about the related models, just how many exist. In this scenario you do not want to load all of the related models into memory to count them, we want our database to do the heavy lifting for us. Laravel offers a number of ways to retrieve relationship counts. 2 have been around for a while, but there is a new kid on the block.

He looks at three methods you can use to get these counts: via the query builder manually, directly on the relationship and, more recently added, from an eloquent collection. He goes through each of these methods, providing a summary of the technique and code examples showing how it's implemented.

Ben Sampson has a tutorial posted to his site for the Laravel users out there sharing some tips about speeding up your database queries when using relationships between models.

Adding indexes to your database tables is a great way to get some extra performance out of your application, especially if you have a large amount of data in your tables. They should be used sparingly and only on identified slow queries, as they have implications of their own such as increased table size and increased RAM usage. But those potential drawbacks are well worth it when you can get a query down from a 3 seconds 15 milliseconds with 5 minutes of work. The effects are particularly noticeable on polymorphic / many to many polymorphic relationships.

He then includes the code required to create the indexes on your tables (either a single column or a compound index involving more than one column) in your migrations. He also provides code examples showing how to use foreign keys to improve one-to-one/one-to-many relationships. More examples include optimizations for many-to-many relationships and polymorphic relationships.

In a new post to his site site Joseph Silber shows you how, when using Eloquent in a Laravel application, to decouple your application from your database by removing hard-coded class names on polymorphic relationships.

Polymorphic relations let you set up a relationship between many different model types, without the need for extra tables. This works by storing the "morphable type" (explained below) in the database, in addition to the morphable type's ID.

By default, the morphable type stored in the database is the model's full class name. While this works, it tightly couples your database to your PHP application. Let's look at how we can instruct Eloquent to use more generic values for these morphable types.

He starts in with a "short refresher" on polymorphic relationships and what Eloquent models look like for a simple customer-to-address relationship. He then talks some about the "morph" type and how Eloquent stores the name of the relating model directly in the record (like AppCustomer or AppWarehouse). He shows how to customize the morph type to map the types to values in a morphMap setting to remove the need for those hard-coded class names. He wraps up the post answering the question many ask: "why doesn't Eloquent do this automatically?"

Junior Grossi has a tutorial posted to his site for the Laravel (well, Eloquent) users out there showing how to work with querying and eager loading complex relationships to access the data from your database.

Laravel is a PHP framework that uses Eloquent, a powerful and amazing ORM that allows you to do complex SQL queries in a very easy way. But sometimes you need more, and here I’m gonna give you an interesting tip that can bring you a lot of flexibility.

He sets up the situation where, as an application grows its needs for interaction with the data evolves and becomes more complex. Laravel (Eloquent) comes equipped with some tools that can help with this. To illustrate, he outlines a basic "blog" application with Post and Comment types and their relations. While it's simple to get the comments for a post, querying them can get a little more complex. He provides some examples using whereHas/orWhereHas but points out an issue with the results (all comments are returned, not just the ones matching the queried posts).

The solution he proposes is to eager load them instead. His example code still uses the whereHas but adds the comments to a temporary variable which is then filtered via a with on the query.

Mahmoud Zalt has a recent post to his Medium.com site that shares a cheat sheet for Eloquent relationships you can use with the Eloquent database layer in a Laravel application.

He goes through each of the relationship types and provides both a diagram showing the relationship and some sample code to make it work:

• One to One
• One to Many
• Polymorphic One to Many Relationship
• Many to Many Relationship
• Polymorphic Many to Many Relationship

The post ends with a combined table of all of the relationships, how they connect with the other models, the number of tables involved and how to set values to a related model.

NetTuts.com has posted the second part of their series looking at the "guts" of a typical WordPress installation. In the first part they gave an overview of the structure and contents of the various database tables. In this second part they get more into the relationships between them.

In the first part of this series on data in WordPress, I gave an overview of the WordPress database tables, and which tables are used to store what kind of data. In this second part, I'll outline how WordPress manages the relationships between that data. As you'll see, WordPress uses three kinds of data relationship - one-to-one, one-to-many and many-to-many. I'll look at each of these and what they mean for your WordPress site.

He goes through each of the relationship types and includes examples from the WordPress database to illustrate them. He then gets into a bit more depth, talking about the specifics of some relationships like: posts-to-users, posts-to-comments, comment-to-comment and the structure of the many-to-many relationships too.

In the latest in their series of PHP community interviews, the 7PHP.com talks with Jacques Woodcock one of the leaders in the Nashville PHP community and of the Nashville PHP User Group (see his previous interview for more on that). In this interview they focus on some quotes from Jacques posted on the SouthernAlpha startup Twitter account about giving back to the community.

The ‘level of wisdom’ in them was too strong to be left there, I had to bring it out and I’m thankful to Jacques ‘TheKit’ Guy for sharing with me (and hence you) his precious experience he gained down the years and elaborating more on those quotes.

They go through each of the quotes and let Jacques expand on them a bit - why he got started with the community, some ways that people can get involved in their local group and remembering that a community is made up of more than just single actors.

Phil Sturgeon has a new post today that looks at the relationship between the PSR-0 standard (autoloading structure) and Composer - noting that they're friends, not relatives.

As a huge proponent of Composer, a happy user of PSR-0 and a voting member on the PHP-FIG I get into plenty of conversations about all of them and it worries me how much confusion there is in the community about these things not actually being related. [...] It seems that a lot of folks discover Composer and PSR-0 at the same time and seem to assume they are the same thing - especially since both Composer and PSR-0 have the idea of a "vendor" and a "package", but those two things are not related to each other either. These are a few points that I have wanted to clarify during some strange conversations over the last few weeks.

He goes on, trying to clear up some of the confusion around the idea of "vendors" and vendor names. He talks about naming schemes and how they may or may not be related to the vendor name on the package. He looks at the PSR-0 loading methods and how the structure of the library/repository effects that (noting that Composer can be made to accommodate something not PSR-0 by default). He suggests that PSR-0 needs to remain "implementation agnostic" and that Composer, at the same time, should remain "specification agnostic" .

In this new post to his blog Michael Nitschinger introduces relationships in using the Lithium framework - functionality to link your models to each other to create dependencies.

The model relationship support in Lithium is one of the hottest topics on IRC lately, so I thought it would be a good idea to blog about it. Currently, Lithium supports 1:1 and 1:n relationships for relational databases. [...] This post gives you a little background on relationship types and their database representations before we implement a simple example in PHP.

He gives some code (and schema) examples of creating these relationships between tables for the two types - one to one and one to many. He also touches on the zero-to-zero relationships as well, nothing that they can be some of the most tricky to work with. He includes the SQL and the code you'll need to produce a blog example with models for Authors, Posts and Groups. Using the belongsTo/hasMany/hasOne variables he defines the relationships and uses the "with" keyword in the find calls to pull in those relations.