I'm fairly confident that OrientDB can handle your problem domain in a much more efficient manner.
Table1 objects would be represented by a Vertex class (derived from V). Table2 objects would also be represented by a Vertex class. The association (relationship) between your Table1 vertex and Table2 vertex object would be made by an Edge class derived from E. So, if A is a Vertex object and 1A, 2A, and 3A are as well, you'd link them together by adding an Edge to A that points to 1A. You'd add another edge in the same way to 2A and 3A. Those links will be bidirectional and managed by the graph database. Hope that helps. -Colin Orient Technologies The Company behind OrientDB On Tuesday, March 3, 2015 at 8:03:52 AM UTC-6, [email protected] wrote: > > Are you using an OrientDB graph database or an OrientDB document database? >> >> > I am doing both. I wanted to have 2 overlapping model. First data linked > (so not embedded) with each other like in a regular relational database, > and second graph linking objects together. > > To give you an implementation idea, one of the use if for a board game. > The "relational" model is to store component data and make links between > data if any. The graph part is to record the geographical position of the > components (tree structure). > > But so far, I tried the document and object API and I am rapidly facing > issues hard to resolve. I might stick to an old relational database with > JDBC, it seems to works much more easily and I am more familiar with > relational databases. > > Thanks again. > > >> -- --- 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.
