On 14 Jun 2011, at 22:51, Michael Hunger <[email protected]> wrote:
> Patrick, > > David Montag created a versioned graph approach on github: > https://github.com/dmontag/neo4j-versioning > > Perhaps you can take some inspiration from that. I'll take a look, thanks. > Otherwise: > Books and Elements are nodes, effects would be relationships which have a > timestamp (probably indexed). > > The relationship between book - [:CONTAINS]-> element would have a validity > time-span. (It is started and open-ended when the element is added and closed > when the element is removed. > > The you could traverse any book along its CONTAINS relationships while taking > the time-span property into account for a concrete timestamp. > > You might choose to add the effect information as additional relationships > between books and elements but perhaps it is enough to add those to > appropriate properties of the CONTAINS relationship. > I'll have millions of effects but thousands of elements for a book so seems a bit inefficient. Wouldn't something like an intermediate layer of nodes of ElementSet (timestamped) make sense instead? A book has many element sets and an element set has many elements. Effects dictate how element sets evolve over time. > Are there other effects as well? > Is it possible to change the content of an element? (that would complicate > the matter) > Otherwise if that is realized as remove the old element and add the new one > this would suffice. > > Addtionally it could be interesting to have links between related elements > (either structural links - part -> chapter -> section -> paragraph | image | > figure | table) or historical, i.e. link elements that replace other to those. > Nope, no other effects and effects can't change (would be remove and readd to amend). My domain is not documents but trading. So my books are a logical organisation of security holdings, my elements securities and my effects trades. Archiving holdings a way of being more efficient of finding the holding at a given point in time without having to process too many trades. P > HTH > > Michael > > Am 14.06.2011 um 21:14 schrieb Patrik Sundberg: > >> I should probably put in some estimates of the sort of orders of magnitude >> of data involved: >> Books are in the 100s >> Effects are in the 10,000s / day >> Elements are in the 100s / Book >> >> On Tue, Jun 14, 2011 at 8:07 PM, Patrik Sundberg >> <[email protected]>wrote: >> >>> Hi, >>> >>> Design question: >>> I have a Book. A book has Elements. To change what Elements are in a Book >>> there are Effects. An Effect adds or deletes an element from a Book (and has >>> other info). Everyday I archive the state of a Book so that I can easily get >>> the state of the Book (it's Elements) at a historical point in time. The >>> number of elements and which elements are in a Book vary from day to day >>> depending on the Effects taking place in the time period. >>> >>> So it's a bit like "Book contents archive of day X + 1 = Book contents >>> archive of day X + the Effects between X and X + 1" >>> >>> There's no need to represent the daily archives in any way, it's the >>> functionality of having historical snapshots that matter to me, so that one >>> can easily get the state of a Book at any point in time by finding the >>> closest archive point before the time and applying the Effects from that >>> archive timestamp and the point of interest. >>> >>> Ideally want to keep a long time history of Book state and Effects. >>> >>> Any ideas for an effecient of organizing this in a graph friendly way? >>> >>> Thanks, >>> Patrik >>> >>> >> _______________________________________________ >> Neo4j mailing list >> [email protected] >> https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
