There are hundreds of ways to "skin the cat" when designing a new database
using all the great tools of OrientDB.
*Can you recommend any good articles, white papers or documentation that I
can read which discuss trade-offs for why you'd use one method/mechanism
vs. another?*
*I am looking to define some common rules for data modeling.*
*Details on how lookup algorithms work in each case could also give the
answers I need to make design decisions utilizing knowledge of dataset
size, etc.*
>> Any books, detailed documentation, etc?
Could the answer be as simple as 'always use graphs to let the data tell
the story'? Probably not, so when not?
Here are some example questions that someone might run across:
*Example 1. Status value as an Edge vs. a property of a Vertex?*
It's the NBA playoffs so let's say I have a list of players (of CLASS
Player EXTENDS V) and each has a status of {"available", "injured"}.
Then *let's say I want to get the list of available or injured players.*
*Option 1a*. Add a property to Player -- e.g. CREATE PROPERTY Player.status
*Option 1b.* Create a new vertex Status and then a new edge HasStatus.
*1a*. select all the players with status = ...
OR
*1b*. select all the players connected to the Status = ... vertex
>>What would be the most efficient query? storage? What are the
trade-offs?
Option 1b(1). SELECT FROM INDEX:Status WHERE key = "injured"....
>>Would indexing the status property of 1a make it just as quick as a named
relationship?
--
---
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.
