Object persistence
•Download as KEY, PDF•
1 like•3,628 views
This document compares the performance of object databases and ORM tools for object persistence. It finds that object databases have easier setup and are faster for storing and retrieving complex objects. However, relational databases with ORM provide better configuration of domain models and easier reporting and data mining. Performance tests showed object databases were faster for create, store, traverse, and query operations while an ORM was slower, especially for queries.
More Related Content
What's hot
What's hot (20)
Similar to Object persistence
Similar to Object persistence (20)
Recently uploaded
Recently uploaded (20)
Object persistence
- 1. Performance of Object Persistence By Vlad Vega Article: "Comparing the Performance of Object Databases and ORM Tools" by Pieter van Zyl, University of Pretoria, Pretoria, South Africa, 2006
- 2. Contents Intro to the Problem of Persistence Relational DBMS + Impedance Mismatch Object Persistence methods Object Oriented DBMS ORM Test & Results Conclusion
- 3. Intro Applications store and retrieve data. Persistence: Storing state. Apps written using OOP methodology. How to store objects into a DB? Most companies use RDBMS to persist data. Intro--RDBMS--ObjectPersistence--OODBMS--ORM--Test&Result--Conclusion
- 4. Relational DB Store data in tables with rows&cols. Foreign key reference relationships. SQL language. Joins used to aggregate inter-table data. Data Mining and Reporting. Intro--RDBMS--ObjectPersistence--OODBMS--ORM--Test&Result--Conclusion
- 5. Impedance mismatch OO encapsulation of object representation. OO Interfaces vs DB Views OO inheritance and Polymorphism. OO List/map manipulation vs. Set OO has atomic primitives vs one unit of revokable work. Intro--RDBMS--ObjectPersistence--OODBMS--ORM--Test&Result--Conclusion
- 6. Object Persistence Methods Relational Database (App layer) Object-Relational DB (Map DB layer) Object Oriented DB (DB is OO) Intro--RDBMS--ObjectPersistence--OODBMS--ORM--Test&Result--Conclusion
- 7. Object-Relational DBMS ORM in DB layer. SQL (but more OO) Data Mining and Reporting Allows user to define Data Types Still closer to relational DBMS. Intro--RDBMS--ObjectPersistence--OODBMS--ORM--Test&Result--Conclusion
- 8. Object Oriented DBMS Simple to Set up. Storage: Objects with pointers to other objects. Query Types: (NoSQL) SODA. Native. QBE Performance of query types. Intro--RDBMS--ObjectPersistence--OODBMS--ORM--Test&Result--Conclusion
- 9. OODBMS Cascading Cascading depth. Transparent Activation. Transparent Persistence. Intro--RDBMS--ObjectPersistence--OODBMS--ORM--Test&Result--Conclusion
- 10. Compare Databases OODBMS Short set up time. Easily changeable Schema. Quick retrieval/save of complex objects without complex SQL queries. RDBMS Impedance Mismatch Joins slow performance. Huge amount of time required for writing queries to persist objects. Intro--RDBMS--ObjectPersistence--OODBMS--ORM--Test&Result--Conclusion
- 11. What an ORM Does Engineer doesn’t write all CRUD queries. Separation of concern: Info hiding. Database Independence Map complex application domain with inheritance, abstract classes, interfaces to RDBMS. Intro--RDBMS--ObjectPersistence--OODBMS--ORM--Test&Result--Conclusion
- 12. Hibernate ORM Persistence API. Relationship Mappings Inheritance mapping concerns Dependencies Domain Model Queries. Configure Eager/Lazy Fetching Concurrency options. Intro--RDBMS--ObjectPersistence--OODBMS--ORM--Test&Result--Conclusion
- 13. Performance: ORM vs. OODBMS 007 Benchmark Complex and simple Objects. Many-to-one, many-to-many. Testing: Stand alone application created with persistence class. Hibernate and db4o implementations added. Intro--RDBMS--ObjectPersistence--OODBMS--ORM--Test&Result--Conclusion
- 14. Results Create+Store model: Hibernate 2.5x slower Traversal through model Hibernate is slower Queries Hibernate is much slower Insert and delete queries: Hibernate 2x slower. Intro--RDBMS--ObjectPersistence--OODBMS--ORM--Test&Result--Conclusion
- 15. Conclusion OODBMS Easy to set up Fast RDBMS+ORM Configure domain model Impedance Match Easy reporting + Data Mining Intro--RDBMS--ObjectPersistence--OODBMS--ORM--Test&Result--Conclusion
Editor's Notes
- \n
- \n
- Many applications today use data that needs to be stored and retrieved.\nMost applications are written in an object oriented manner.\nWhat is the best approach when storing objects into DB?\n
- Which DB is mostly used in industry today? Relational. I want give you a short descriptions of rdbms and then show you why it fits poorly with OO application code.\nRelational databases store data in table format with rows and columns.\nRDBMS uses foreign key relationships to refer to rows in different tables.\nSQL is used to communicate with the DB: read from, write to, create schema. Developers love this because they can directly interact with db, look at aggregate data. Ingrained into CS society.\nSQL joins are used to aggregate data from multiple tables for both data-mining and normal read-write functionality. SQL can give you data independent of the the object schema in the application.\n
- Encapsulation objects (=hidden representation) is an OOP concept that is not held with a RDMBMS because you can query and change data in encapsulated objects.\nAccess to objects in object-oriented programs is allegedly best performed via interfaces that together provide the only access to the internals of an object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects,inheritance and polymorphism are not supported by relational database systems.\nManipulative differences: RDBMS perform set-based operations on the data while OO languages deal with lists and hashtables.\nTransactions: With DBs, transactions are usually multiple queries that consist of multiple changes in maybe multiple tables until all the functionality of a given procedure is finished. Generally OOP languages have ensured atomic consistency of only primitive variable writes.\n\n\n\n\n \n
- There are other kind of DBMSs \nIn an OO database the application objects are stored as objects.\nIn an Object Relational database the Object-relational mapping happens in the DB layer while the data is stored in a relational manner.\nWith a relational database, all object persistence must be done in the application layer. The use of ORMs like hibernate and active record are popular.\n
- Engineers can Still use SQL.\nData mining is still just as easy and possible.\nObjects, classes and inheritance are directly supported in database schemas and in the query language. In addition, it supports extension of the data model with custom data-types and methods.\nExample code: Customer table C has a reference to an Address table in which there is a City column. You can write queries like this from your application if you use ORDBMS. \n
- -It literally took me 5min from download to run my first query.\n-Data is not stored in tables. It’s actually stored like it is in memory: objects with pointers to other data structures and objects.\n-OODBMS query types: SODA (simple object database access), QBE (query by example), and native query (very object oriented query code- easy to read, type safe). (Show code and explain)\n-SODA query api is the oodbms low level api. Not type safe nor compile time checked. Use native queries instead but there are instances where you may need dynamically built queries => use SODA.\n-talk about how to query data when you store pilots in a car object: specific pilot prototype in QBE or car.getpilote.getname= "mike" in native\n\n\n\n
- Cascading update + delete problems occur from updating all objects in an object’s collection member. Use what people frequently call lazy loading (at least people that work with the hibernate ORM). This simply means that when you load an object into memory from the db you do not extract all of the objects associated with it, but only extract them as they are required by the code dynamically. Same goes for updating an object (do you update all collections also? \n-db4o uses Activation methodology which retrieves data lazily and then further depth as required. In db4o it is as easy as simple “implementing the “Activation interface” => which gives you lazy loading.\n-Configurations that you need to handle with object persistence mechanism are super simple and you can use the EmbeddedConfiguration db4o class. Choose preferred depth of cascading. Then you can choose to create a new config when processing a different object.\n\n-All Inheritance, Array, data structure issues are handled in the application layer as you would handle the object if it was not in the db. \n\n\n
- -RDBMS joins are the main factor in RDBMS that slows down performance.\n-in OODBMS it is really easy to change the schema of the DB- make very little changes to the code in order to do that. Sometimes this can be difficult with complex relationships in RDBMS.\n-\n\n
- -Acts as a “separation of concern” between object persistence and application business logic.\n-Database Independance: allows api to communicate even if you change to a different DB.\n-It is not easy for engineers to map a complex domain model to a relational schema and once you have a schema set it is not simple to change it.\n\n\n
- -Provides database communication api. Deals with session scope, DB transactions and rollbacks. For example- like I found a couple months ago, each time you store an assortment of objects in a db it needs to be in the same transaction because if u are store for instance 3 objects (dependant or not but for an action to be completed they all need to be completed) then you cannot first store one than another outside of a db transaction. Firstly, it slows the process and secondly if the second fails then the first save is not rolled back (uh oh- find it run a sql query....)\n-Relationship mappings: Most Difficult part. Say there is a many-to-many relationship btw objects A and B: you need to specify that a table with PKA+FKB and PKB +PKA needs to exist.\nDeals with inheritance concerns: Hibernate allows: 1class/table (duplicate info): 1 big table with all classes and a column to differentiate. \n-Dependencies: when an employee instance gets deleted so should it’s accompanying home address class.\n-Instead of writing SQL you will be writing domain model queries like: SELECT FROM com.proj.Employee WHERE weeklySalary > :salary (in other words you dont deal with tables- just objects and members. However- this has a drawback because instead of a plain SQL query you are always retrieving extra columns beyond the ones you are actually using. (at one point u will use some columns at another point in the logic, different ones will be necessary=>lower performance) \n-ORM allows you to specify how you deal with concurrency:\nOptimistic: longer transactions, longer sessions. vs Pessimistic, short transactions to avoid concurrency. Optimistic: transaction rolls back. Pessimistic: locking mechanisms.\nHUGE OVERHEAD\n \n\n
- \n
- \n\n
- \n
- \n