ORM: Mistakes

General rules

If you can avoid using ORM – so be it.

If you can avoid using SQL – so be it.

If you can avoid using DB – so be it.

If you cannot – use them wisely and remember about previous rules.

Project #1: Social Network

Goals:

People network, add, edit and share content, groups, effective ads, full content search, connection adviser etc.

Used:

JDBC + SQL + PL\SQL

Oracle

Result:

Failure. Low performance. High improvement cost.

Project #1: Why failure?

Was:

Manual data mapping to objects.

Huge unmaintainable queries.

Number of classes without business logic.

High cost of scaling.

Should have been:

Auto-mapping.

Simple, understandable queries.

Only code which supports business logic.

Cheap scaling.

Project #1: Social Network

Conclusions:

Pure SQL – medium query speed, slow development.

ORM – slow query speed, fast/medium development.

Graph DB – fast query speed, fast/medium development.

Project #2: CMS

Goals:

Add, edit and share content, groups, security, full content search, 3rd party integration etc.

Used:

Document oriented DB (Jackrabbit)

Portlets + JSF

Result:

Failure. Mostly because of UI requirements.

Project #2: Why not classic ORM?

OR Mapping:

Complex DB structure.

BLOBs and CLOBs.

Complex search.

Very complex permission model.

DO Mapping:

Hierarchical structure.

Native document/content support.

Clear search query language.

Permissions/groups may attach to each document.

Project #2: CMS

Conclusions:

Hierarchical security model – painful for any RDBMS solution.

Content is important – it is not just bytes.

Document oriented mapping – for documents.

Project #3: Market Auction

Goals:

Allow participants put bids, simple security, complex business rules, real-time.

Used:

ORM (Toplink) + QL + SQL

Oracle

Result:

Success (partial). Could be better without ORM.

Project #3: Without ORM?

ORM:

Frequent domain object transformation.

Slow as for real-time system.

Complex mapping.

Almost impossible query optimizations.

Useless cache and other ORM cons.

Native SQL:

Storing method is unique for all objects.

Fast.

Do not require mapping. Flexible.

Easy to optimize.

Avoiding unnecessary operations.

Project #3: Market Auction

Conclusions:

ORM – heavy and huge.

Real-time – usually means NO ORM.

Financial data – RDBMS is the best.

Project #4: IO System

Goals:

Import/export moderate volume of data, allow data modification, simple security, medium business validation, no business rules, several DB engines support.

Used:

ORM (Hibernate) + QL

Oracle, MS SQL and potentially others.

Result:

In progress. Hope of success.

Project #4: Why ORM?

No specific value/transfer objects.

Very simple queries.

Cascade insertion.

Multiple DB support.

Simplified UI.

Well-known FW.

Questions?