Concept for modeling hierarchical data 2005-12-13 - By Dharmendra Sharan
Back
Hi Florian,
I haven't used Object Oriented databases as such, but have mostly come
across Relational Databases which seem to be the mainstream approach, and works
for most cases.
In case you feel there's a strong reason that the application's usage
profile would rely and "heavily" use the hierachical relationship, then you'd
need to check whether it makes more sense to store your Java objects natively
in an OO datbase as opposed to serializing them in XML and storing them in an
XML database and work in that manner. Here are some vendor names for the same:
a. Object Oriented data model
- Excelon/Object Design (optimized for OO storage/rerieval)
b. XML based data model
- Tamino (optimized for XML storage/retrieval)
- Xindice (optimized for XML storage/retrieval)
- Excelon/Object Design
c. Relational data model (optimized for Relational storage/retrieval)
- Oracle
- Sybase
- SQL Server
- MySQL (opensource!)
- DB2
....
Hope this helps,
Dharmendra
ps: have a good day!
-- --Original Message-- --
From: A mailing list for Java(tm) 2 Platform, Enterprise Edition
[mailto:J2EE-INTEREST@(protected)]On Behalf Of Florian Lindner
Sent: Sunday, December 11, 2005 3:11 PM
To: J2EE-INTEREST@(protected)
Subject: Re: Concept for modeling hierarchical data
Am Sonntag, 11. Dezember 2005 20:30 schrieb Chris Gerrard:
> Tim Wood wrote:
> >At 05:28 AM 12/11/05, Florian Lindner wrote:
> >>Hello,
> >>I'm searching for the best concept of how to use and save hierarchical
> >> data. I have a structure like PC file system with meta data. There a
> >> folders and files of different types. Every object have data like
> >> permissions, date and author. And they have type-specific data fields
> >> like resolution (of an image type) or location (of an meeting type) or
> >> ingredients (of an recipe type). What is the best way to store that kind
> >> of data? What database is recommendable? What concepts of persistance?
> >> Or not using managed persistance and do it manually?
> >
> >Florian,
> >These are all important questions, but they cover different levels. Start
> > with a clear data model, expressed in entity-relation form. Make sure
> > you capture the major object types and all their attributes. Err on the
> > side of high normalization, creating joining tables to tie objects that
> > can be combined arbitrarily. In the classic personnel schema, you could
> > have an Employee table, a Manager table and a ManagerReport table to
> > express each manager's reports. (Managers are employees too, so the
> > model must reflect that, etc.) Make sure you can support the major use
> > cases with the data model, and allow flexibility for future ones.
> >
> >Once you understand the data model, you have choices for expressing it.
> > The Hibernate object-relational package is powerful and quite mature.
> > You can map objects directly to tables or in v3 you can map them to
> > stored procedure invocations. This allowing you to leverage more of the
> > DBMS functionality, possibly at a cost of some DBMS independence, since
> > stored procedure behavior can vary. In particular, you can put most of
> > the transaction responsibility in the stored procedures instead of
> > managing it in code with JTA or using the container (app. server)
> > features. In conjunction with good index declarations, this can produce
> > a system that is quite fast.
> >
> >Just some thoughts out of my experience.
> >
> >HTH,
> >TW
>
> Of course, Tim's response assumes one is using a relational database for
> persistence. It may well be that some other persistence store is
> appropriate, particularly in this context where therre seems to be a
> natural hierarchical structuring of the information.
>
> Do you have a clear information model, distinguished from a data model?
> How about an object model? Even if you end up using a RDBMS these will
> help guide you.
Right know I don't have any concept of my data model or application, just some
unstructured thoughts. What about using object-orientated databases? Are
there good java compatible OO-DBs around?
Florian
===========================================================================
To unsubscribe, send email to listserv@(protected) and include in the body
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected) and include in the body of the message "help".
|
|
