@xvik: Correct. And the idea of extending a common base class and then
including @class in the WHERE clause is essentially what I was looking at
for the "no property" approach. I suppose the follow-on question here is
whether it's faster to test @class vs a property (again, this example would
never have more than a few contacts per person, but think in terms of
having tens or hundreds of "Contacts" per "Person"). I would assume that
even on a very large scale, @class is faster and more efficient, since that
approach is possible using a lightweight edge.
--Eric
On Friday, July 10, 2015 at 2:09:54 PM UTC-5, xvik wrote:
>
> If I understand correctly, the author is trying to generify contact
> information.
> So we have Person extends V and abstract Contact extends V classes.
> Each contact could be defined in its own class: Phone extends Contact,
> Email extends Contact.
>
> In such case, I see no reason for different edge types or using edge
> properties: we need just one edge ''has_contact".
> Contact type could be resolved by its class: e.g. to get person address
> select from (select expand(out('has_contact')) from #personId) where
> @class='Address'
>
> суббота, 11 июля 2015 г., 0:54:15 UTC+6 пользователь scott molinari
> написал:
>>
>> Ok, but phone and email aren't really types of edges you would normally
>> create. They don't indicate a relation. In OrientDB, you'd store the email
>> and phone as properties of the vertex or document class. An edge would be
>> something like "isA". Person->isA->Contact. Granted, I have to admit, my
>> knowledge of ODB is limited, but from everything I've read and seen thus
>> far, you just wouldn't create edges like that.
>>
>> Can you post a link to the article about Neo4j you mentioned above?
>>
>> 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.
