To ORM or Not To ORM

ORM or Object Relational Mapping give developers easy access to the database by connecting objects to database tables. ORMs are easy to use and set up, but can cause performance problems for complex queries. Here are a few tips on when to use the ORM and when not to:

To ORM

ORMs should be used when querying database models since they enable you to query the database directly from your code. As a result, you do not have to write extra SQL code in your applications. ORMs make the code base cleaner, easier to maintain and highly readable by centralizing the data models. This makes it easier for other developers to understand and add value to the code base. Therefore, you should use an ORM if your priority is to build lean applications.

Not To ORM

ORMs should not be used when there is a need to specify exactly what SQL runs on the database. For example, ORMs should not be used in data migrations because they permanently change the state of the database. Furthermore, database migrations done via the ORM that update data will update ALL of the data. Therefore you should know exactly what SQL code is executed during database migrations. ORMs should not be used for simple sql scripts that don’t need to be maintained or run more than once. ORMs can also lead to performance issues for complex SQL queries if not configured properly.

In conclusion, ORMs are very powerful and can make your lives better when used properly. ORMs allow you to start developing lean applications quickly and easily. In most cases, you should use an ORM when querying database models instead of writing those queries in SQL. However, queries that change the state of the database like migrations or one-off scripts should not be done via an ORM. Remember, with great power comes great responsibility so be careful or get tangled in the webs.