It seems to me that OrientDB's way is more versatile. The 5 scenarios would be UNIQUE INDEX ON
1. no index 2. (in, out) 3. (in) 4. (out) 5. Two indices. (in), (out) Why OrientDB is more versatile is that you could also include one or more edge properties in the index. So for example, if you are tracking the user who creates an edge and you want a user to have at most one edge connecting two vertices. Then the unique index would be on (in, out, user) On Tuesday, October 27, 2015 at 5:30:36 AM UTC-7, scott molinari wrote: > > Hi, > > This comes from a discussion and resulting inquiry in the ODB Gitter chat, > which got overlooked. > > It seems there is a way to control multiplicity of edges in ODB through > edge constraints. > > http://orientdb.com/docs/last/Tutorial-Using-schema-with-graphs.html (towards > the bottom) > > The edge constraints are one of those usability things that make ODB less > user friendly IMHO. > > Here are some multiplicity types taken from Titan's manual (because the > way they are explained is simple to understand): > > MULTI: Allows multiple edges of the same label between any pair of >> vertices. In other words, the graph is a multi graph with respect to such >> edge label. There is no constraint on edge multiplicity. >> SIMPLE: Allows at most one edge of such label between any pair of >> vertices. In other words, the graph is a simple graph with respect to the >> label. Ensures that edges are unique for a given label and pairs of >> vertices. >> MANY2ONE: Allows at most one outgoing edge of such label on any vertex in >> the graph but places no constraint on incoming edges. The edge label mother >> is an example with MANY2ONE multiplicity since each person has at most one >> mother but mothers can have multiple children. >> ONE2MANY: Allows at most one incoming edge of such label on any vertex in >> the graph but places no constraint on outgoing edges. The edge label >> winnerOf is an example with ONE2MANY multiplicity since each contest is won >> by at most one person but a person can win multiple contests. >> ONE2ONE: Allows at most one incoming and one outgoing edge of such label >> on any vertex in the graph. The edge label marriedTo is an example with >> ONE2ONE multiplicity since a person is married to exactly one other person. > > > Needless to say, because of this kind of abstraction, implementing such > multiplicity while creating edges in Titan is fairly straight forward and > simple. In ODB, well, it isn't quite so transparent or simple. This is > along the lines of the requested usability abstraction discussed in this > issue on Github > <https://github.com/orientechnologies/orientdb/issues/3820#issuecomment-151162243> > . > > Let's go through the possibilities and see how ODB does them (and > according to my understanding of ODB, which admittedly isn't great, so I > could be wrong. Please correct me if I am!). > > MULTI > > This is a standard heavy weight edge in ODB. So, creating a heavy weight > edge follows the MULTI multiplicity rule automatically. > > SIMPLE > > This seems like it would fall under the "UNIQUE" indexing method of an > edge. However, I don't think that is completely right, because the UNIQUE > index enforces a single in and out between two vertices. So using a UNIQUE > index is more like the ONE2ONE. I believe this might be the equivalent to a > light weight edge, but with an added unique index.(?) > > MANY2ONE > > I believe this can be done with the in and out constraints. > > ONE2MANY > > Same as above. > > ONE2ONE > > Available through the UNIQUE constraint. > > So, through this exercise, I think I have learned that ODB can cover all > multiplicity scenarios, though, I am absolutely not certain. Why must I be > uncertain? This whole concept could be simplified by using the same terms > Titan uses. It seems the abstraction is necessary. I believe it would make > ODB easier to understand. > > Maybe these suggestions could be worth thinking about. Starting from the Cars > database example taken from the docs > <http://orientdb.com/docs/last/Tutorial-Using-schema-with-graphs.html>. > > Creating the edge classes stays the same. > > orientdb> CREATE CLASS Owns EXTENDS Eorientdb> CREATE CLASS Lives EXTENDS E > > > SIMPLE (a standard light weight edge, but automatically allows multiple > light weight edges, which seems a step above TItan!) > > orientdb> CREATE EDGE Owns FROM ( SELECT FROM Person ) TO ( SELECT FROM Car ) > > > MULTI (an edge with properties is created/ heave weight edge, with in and > out mandatory) > > orientdb> CREATE MULTI EDGE Owns FROM ( SELECT FROM Person ) TO ( SELECT FROM > Car ) > > > MANY2ONE (not sure what needs to happen with in and out here) > > orientdb> CREATE MANY2ONE EDGE Lives FROM ( SELECT FROM Country ) TO ( SELECT > FROM Person ) > > > ONE2MANY (same as above, not sure about what needs to happen with in and > out) > > orientdb> CREATE ONE2MANY EDGE Owns FROM ( SELECT FROM Person ) TO ( SELECT > FROM Cars ) > > > ONE2ONE (this is a heavy weight edge, with an automatic UNIQUE constraint) > > orientdb> CREATE ONE2ONE EDGE Owns FROM ( SELECT FROM Person ) TO ( SELECT > FROM Cars ) > > > UNIQUE (an additional constraint, only for light weight edges) > > orientdb> CREATE UNIQUE EDGE Owns FROM ( SELECT FROM Person ) TO ( SELECT > FROM Car ) > > > > To be honest, I am really not sure this covers all needed or wanted > possibilities, when it comes to edge direction constraints or multiplicity. > However, I know for a fact the above suggest SQL is a lot easier for me to > understand., which is the goal of a declarative language like SQL. We are > abstracting out three things as I see it. Edge type creation (light or > heavy weight), edge direction and multiplicity. > > As I look back at what I just wrote, I guess what I am uncertain about is > how to actually create many-to-one and one-to-many edges in ODB. > > Any other thoughts on this and corrections to my thinking would be greatly > appreciated. > > 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.
