Hi Benjamin, On Tue, Aug 30, 2011 at 3:16 AM, Benjamin Gustafsson < [email protected]> wrote:
> Hi > > I'm trying to figure out how to design a graph database where I have > > 1. Users > 2. Groups > 3. Items > 4. "credit_line" -relation between Users. A balance of credit. > 5. "credit_line" -relation between Users and Groups. > 6. "memberOf"-relation from Users to Groups. > 7. "have" -relation between User and Item. > 8. "display" -relation between Item,User and User/Group. (A triple) (a Item > belonging to a User is displayed as available for only a specific > group/user, or multiple groups/users. This is unclear how it should be > represented in neo4j, does it need a node?) > If an item can only be "had" by one user at a time, then the "display", or "visible_to", relationship could originate from the item. > 9. "owesItemTo" -relation between User, Item, User/Group. (A triple, Do I > need a node?) > Same here. > > The credit line will have limits. [Credit given by node A and Credit given > by node B] These limits defines the credit line. > > My thoughts are therefore to place the balance accounting as a property on > the edges in the database. > > Node:User -- Edge with Property: Credit line, value -- Node:User > Node:User -- Edge with Property: Credit line, value -- Node:Group > > But I feel that this approach is kind of weak. I really don't know how to > represent the credit line. (Maybe it needs a node... Because if I use two > directed edges they need to be synchronised all the time. If A owes value > to > B, B owes -value to A) > Why would you need two relationships? Can you let a single relationship represent the mutual credit line between two users? > > How would you have designed this? > > It is to be used as a multi user database. > I will therefore use a lot of transactions in the application, editing > balances between users and groups, in long chains as atomic actions. (This > has to be quick so that the same node and edges can be used by the next > transaction.) > > I have thought about traversal algorithms that may be executed in advance > to > find a path. And then try to use the pre-discovered path in a quick > transaction, or roll back if the path no longer has enough credit available > in all the chain. > > To understand how my credit line should be used you can take a look att > ripplepay.com. But I'm designing a barter system with items. > -- > //Benjamin Gustafsson > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > -- David Montag <[email protected]> Neo Technology, www.neotechnology.com Cell: 650.556.4411 Skype: ddmontag _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
