Normal vs Polymorphic Relationships

Does anyone have anything to say on this?

I've used polymorphic relationships in a legacy application database before and although they can be useful I'd only recommend them when you have no other choice and you'll only use a couple of them. Otherwise (and this is just my experience) all the time involved in planning and/or modifying your database schemas to comply with the requirements of polymorphic relationships (assuming you have the freedom to do that) and solving the weird bugs that can come up would be better spent learning and implementing a data mapper.

I mean, Active Record is great, I love it and use it whenever I can, but it seems Data Mapper is a better tool for your particular use case. I know there are a couple of laravel specific data mapper packages out there but can't remember the names just now.

EDIT: I found one of the packages I mentioned before https://github.com/analogueorm/analogue

Wow this one of the better answers I've Ever Ever Ever seen on the forums. Plus read http://laravel.io/forum/05-12-2015-has-many-through-relationship-depth And
http://laravel.io/forum/04-04-2015-looping-through-collection

When designing your database, I would first concentrate only on the database schema. Forget the code which will use it. If the db schema is not designed properly, no PHP code can fix that. On the other hand, if the db schema is designed correctly, you can always improve or change the code on top at some point.

So maybe at first you'd use Eloquents relations to quickly load stuff. But if in the future you find out it causes a performance bottleneck, you can always rewrite a few methods to use plain MySQL queries to improve performance.

@Mattiman beautiful answer!

Thanks for the answers! Is there an answer for "When should I use polymorphic relationships over normal relationships?"

Also, is it better to start with normal relationships and later on switch to polymorphic relationships or will that cause chaos?

I think it also depends on what exactly the models are and the db structure that fits best. If you read here you see one example http://laravel.com/docs/5.0/eloquent#polymorphic-relations but I think that the Wordpress database schema also uses some sort of polymorphic relationship if you look at the tables wp_term_taxonomy, wp_term_relationships (this is the m-m pivot) and wp_terms. It stores multiple taxonomies in one set of tables.

In a project I'm working on I use polymorphic relations for Tags, because multiple models can be "taggeable". Say Posts, Articles, Widgets, etc. So instead of creating three separate many to many pivot tables for each of the models, I only have one.

Is it recommended to use polymorphic relationships for every one model can be connected with many models situation, like the tags example in the docs? I am asking these questions because at the start of a project, you may have only 2 models which can be connected to one model (example a Group model can be connected with 2 other models and contain 2 types of different groups in one place) but later on you may add more of those.

Hi @Ruffles, I'm not entirely sure if I fully understand your question. There are basically two levels of decision you have to make:

• on the database level: decide which tables you need and how they are related. This step is important, because changing the db is usually more difficult then changing code
• on the code level: decide how the eloquent model relations are. This will mostly result logically from the db structure chosen in step 1, but you can change or add relations on top of that. So in the example of the Taggeable polymorphic relation, maybe at first it's only related to Posts and Pages, but later you will also add a relation for Images. So yes that's possible. Just depends on the specific needs.

Ok, cool! What about performance? Is it better to search for different types of tags in one place (polymorphic many to many) or do some joins for multiple many to many pivot tables? (tags for photos and articles)

Sorry I'm no database expert so can't give a full answer to that. I do know that normally db queries are very fast, as long as properly constructed and well indexed. Whether you join 2, 3 or 4 tables doesn't matter so much then. A join on a few thousand rows can be slow if not properly constructed, a join on many millions of rows can be blazingly fast if constructed/indexed well.