Is it? Is it not? “ORM is an anti-pattern” | Seldo.Com Blog

If you are into whether you’re going to use ORM in your next project or not, you’ll appreciate the thoughts about why and when ORM can be bad for the application. First its design flaws are shown and then alternatives are given. Too many queries, the need to break the abstraction by using raw queries, how bad it can be in the long term when it’s too late and many more:

ORM is an anti-pattern | Seldo.Com Blog.

I personally like ORM, defining the relations properly and then having the powerful code coming from this abstraction. I am on my way to use ORM in a big project too. I also know and use SQL a lot for example in data mappers. I think sometimes it may be better to create a custom in-house ORM for a project though this may require constant changes to it when adding new features. I also think that every query produced by the ORM should be checked before going in production and also using a monitoring tool for your application in prod and testing your application by overloading it in a dev environment is good.

Defining relationships among database tables with Eloquent @ blog.andreasartori.me

One very clever article showing all types of complicated relations that you may stumble upon in your job.

The author shows in a very clean way how to create such migrations, seeds and models.

Check out how morphs(), morphTo(), morphToMany(), morphedByMany and withPivot() are used.

Read it a couple of times, test it with all possible databases Laravel supports and see the differences, check the structure created: tables, data, foreign keys. Add, delete records and see what happens inside the database. Try creating your own app using these functions to get even more clear picture.

Laravel, Eloquent, polymorphism, one-to-many, many-to-many and polymorphic many-to-many relationships:

Defining relationships among database tables with Eloquent.