Good question. I have not used versions with bitemporal yet, but I think you should keep something to tell you which version of a schema/record you have so you can programmatically handle different formats later (if old data has different/missing elements vis new data). If it is not uniform and easy to access in the content itself, adding it to the header will help.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Hank Ratzesberger Sent: Friday, June 12, 2015 5:11 PM To: MarkLogic Developer Discussion Subject: Re: [MarkLogic Dev General] Transitioning from SQL Hi Damon, Thanks, good point. there's some provenance and metadata that the Entities are not going to bring across. Question, should a header include a version,or is that a moot question with "bitemporal" data, that is, what are the tradeoffs ? Regards, Hank On Fri, Jun 12, 2015 at 10:57 AM, Damon Feldman <[email protected]> wrote: > Hank, > > I think your idea to store something similar to the existing entities in your > Java layer is a good one, at least as a starting point. NoSQL Document > databases tend to hold data in some primary, natural form where each document > is a natural business object. These tend to correspond to some typical > messages or service results that are needed from the system. > > So if your Java system is sending out "Invoice" documents in a web service, > then that is likely a natural grouping of data (natural business entity) that > should be stored in MarkLogic. > > I recommend, these days, always using the "envelope pattern" where you define > a persistent envelope document and put your business entity in there with > some additional header section: > > <envelope> > <header> > Ingest date, doc size, security markings, normalized dates, > etc. > <header> > <content> > <invoice> > [...] > </invoice> > </content> > </envelope> > > This is nice because you can change formats or data inside the <header> > section and your Java application can still pull out just the <content> > portion without your header changes affecting the content. It decouples the > DB changes and Java dev changes. > > Damon > -- > Damon Feldman > MarkLogic Corporation > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Hank > Ratzesberger > Sent: Thursday, June 11, 2015 5:48 PM > To: MarkLogic Developer Discussion > Subject: [MarkLogic Dev General] Transitioning from SQL > > Hello, > > We have several Oracle databases that we access through different > users/schemas and even Database Links. Altogether a fairly complex data set. > > Our applications are mostly J2EE, so we have a lot of entities or we could > create others, that are complete objects representing the "things" that the > application is built on, for example, an Invoice with all its Line Item and > Funding documentation. We might be able to use the Java API to iterate > through these and serialize them to ML. > > Any white papers or case studies or your general feedback on how to reap data > from an SQL database into MarkLogic would be appreciated. > I've just begun to think about this, hopefully my question is not too vague > and with some feedback I can narrow my questions to something more specific. > > Thank you, > Hank > > --Hank Ratzesberger > _______________________________________________ > General mailing list > [email protected] > Manage your subscription at: > http://developer.marklogic.com/mailman/listinfo/general > _______________________________________________ > General mailing list > [email protected] > Manage your subscription at: > http://developer.marklogic.com/mailman/listinfo/general -- Hank Ratzesberger XMLWerks.com _______________________________________________ General mailing list [email protected] Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
