I understand your point, but want to warn - if we are talking about graph database - understanfing, that edges are "first class citizens" - is essential.
Working with relations directly, thinking of them as of real (not hidden) part of the system is what makes this concept so powerful. As in example with MarriedTo - it is ok to have this kind of link (named MarriedTo) in Document or Relational database and Ziink's first suggestion was to emulate that way for if you are easier with links. But here, in a Graph world - you have to think about directions and true meanings of relations you are going to map. As of my suggestion to think about uniquness of edges - cardinality is just subset of way more possible constraints. You might have more properties in every edge and then, again, make them unique or not. On Monday, November 2, 2015 at 1:03:21 PM UTC+5, scott molinari wrote: > > You see, that is the problem with me. ODB says, "Use the graph API, > because then the graph relationships are handled automatically for you:" > Well, that seems to be true, but only to a point. When you say I have to > still think about relationships being stored in some list and that vertexes > are actually oblivious to how they relate to other vertexes, well, to me, > that isn't a graph database. That is a document database with edges stored > in a collection of documents. > > In other words, the fact that is actually what is happening in the > background, shouldn't matter at all. The graph database should abstract the > relationships to be meaningful, both from a graph usage perspective and a > database operational perspective. > > Scott > > > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
