Concept for modeling hierarchical data 2005-12-11 - By Florian Lindner
Back
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".
|
|
