On Monday, February 18, 2002, at 08:25 AM, Mark J. Stang wrote:
Yes and no ;-). In my application I have a customer who has a vehicle which has repair orders. There are three collections there. When they view it on the screen it is a tree. The customer part of the tree comes from the "customers" collection. It owns a vehicle from the vehicle collection. Basically, I embed the key in the customer document and when I display the vehicle, I get the vehicle document from the database. Each vehicle can have n repair orders. The are accessed via a key also.
They can view the customer info, vehicle info and repair order info on the customer screen.
On my Appointment screen someone has scheduled an appointment for a particular repair order. They can click on the appointment and expand it and see the repair order. The appointment list is also a document in an appointment collection that has the repair order key embedded in it.
So, now they can go to two different screens and see the same data. And in the db I have two or more documents referencing the same document all in different collections.
So sometimes it looks like n "big"(composite) documents and other times it looks like a single document.
Ok, linking, this is one of the features up for debate. Right now we have auto-linking which does this kind of thing, but with a few serious issues.
From your experience, do you see this getting deeper into the database?
What you just said is what I am attempting to create as we speak, using JMS and caching.
Well I'm two for two on reinventing the wheel today. :-) At least this one is an idea I've had for about six months, the other one I reinvented when it was already described by another email in my inbox. It's really cool to hear that people are already working on some advanced concepts.
Kimbro Staken XML Database Software, Consulting and Writing http://www.xmldatabases.org/
