ORM: Mistakes
Jul 07, 2015
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?