Object-relational mapping

From DocForge

Object-relational mapping, or ORM, is a programming technique which corresponds data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.

Advantages [edit]

• ORM frees the programmer from dealing with simple repetitive database queries. Instead of writing SQL, the programmer can request objects from the ORM's persistence layer and call a save procedure after updating an object. Alternatively, some ORM libraries will automatically persist updated objects, such as during garbage collection or system shutdown.
• Conceptually, automatically mapping the database to business objects lets programmers focus more on business problems and less with data storage.
• The mapping process can aid in data verification and security before reaching the database. Proper data can be confirmed and appropriate messages can be returned to the user without relying on failed database queries.
• ORM can provide a caching layer above the database. For example, if the same object is requested multiple times, it's possible for the ORM layer to retain and reuse the same object, rather than re-querying the database.

Disadvantages [edit]

• ORM adds a least one small layer of application code, potentially increasing processing overhead. ORM can speed development time and lower complexity, but "manually" dealing with database interaction can be more efficient. Therefore, using ORM can contribute negatively to memory consumption, CPU usage, and code bloat.
• ORM can load related business objects on demand. To keep it simple, this usually involves many small queries to load data as needed. This can sometimes be slower overall than using one complex query due to the overhead of query processing and server communications. This trade-off is very dependent on the underlying database implementation.
• Some data related tasks, such as bulk inserts, updates, and deletes can be overly cumbersome when done through ORM. It's typically far more efficient to perform these tasks directly through SQL, sometimes via stored procedures.
• An ORM system's design might dictate certain database design decisions. For example, each table might require columns to be of specific types, or table relationships might need specific table structures. These requirements can potentially adversely affect database design by lowering performance, making it harder to write custom queries, or making it difficult to share with other systems.