I don't know why the requirement for actual separate datastores - but would a document store be more appropriate? You could segment at the client nodes (or anywhere, really), have ONE actual document store, and allow each client to see a different document root - they'd have no access to any other client data.
On Thu, Jan 27, 2011 at 11:30 AM, Greg Reddin <[email protected]> wrote: > I'm working on a portal for doing analysis and reporting of survey > results. I'm trying to find the best strategy for segmenting multiple > clients' data with an O/R mapping tool like Hibernate. > > The metadata structure is a parent-child relationship like this: > > client -> study -> project -> variable -> value > > A client has one or more studies. A study consists of one or more > projects. A project consists of multiple variables that make up the > questions on the survey and/or respondent attributes that are used in > reporting. The values are the code lists of valid responses that are > available for each variable. Questions that are "open-end" in nature > do not have a list of predefined values. The relationship between a > study and a project is somewhat fluid at the moment and may change. > > We need a shared data store to contain a list of all the clients and > studies/projects. But, naturally, each client wants their own data > contained in a database separated from other client data. That's the > metadata structure. The actual survey data that we report on and > analyze is contained is a separate flat table for each study/project. > > This metadata structure is easily modeled with OR mapping tools. But > they all seem to fall apart when you need to contain each > project/study's data in a separate database. You really need a > separate SessionFactory or EntityManagerFactory for each one, but they > all contain identical class structures with identical O/R mappings . > Could anyone share your experiences with implementing something like > this? > > Thanks, > Greg > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Joseph B. Ottinger http://enigmastation.com -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
