Luca,
Thanks for the reply, but edges wouldn't help my situation either. The
trouble comes when you are dealing with massive amounts of data. Any
classes above 5-8M vertices really needs indexes for better performance.
In the queries provided the problem occurs when an index needs to go
across properties from two classes (Employee + Company in our example). The
index or filter needs to include properties from both to return the correct
key matches. The statements you provided only index one property for each
class. The indexes don't go across. Imagine Jay worked not only for
Commodore but also Atairi. That means you need to filter/match against
employee id AND company name to return the correct results. Due to massive
data, you need an index. I don't see a way to have an index currently since
they require all needed properties to belong to the class it's created
under. I tried a similar pattern like the one you listed earlier but the
performance isn't fast enough since not all of the properties are part of
the index.
I hope that made sense :)
Thanks again for the quick reply,
Ronnie
On Tuesday, August 4, 2015 at 8:17:14 PM UTC-4, l.garulli wrote:
>
> Hi,
> You should use the Graph API, then create a flat index against
> Company.name:
>
> // CREATE THE SCHEMA FIRST
> // ----
> CREATE CLASS Company extends V
> CREATE PROPERTY Company.name STRING
> CREATE INDEX Company.name UNIQUE_HASH_INDEX
>
> CREATE CLASS Employee extends V
> CREATE PROPERTY Employee.name STRING
> CREATE INDEX Employee.id UNIQUE_HASH_INDEX
>
> CREATE CLASS employedBy extends E
>
> // CREATE THE GRAPH
> // ----
> CREATE VERTEX Company set name = 'Commodore'
> CREATE VERTEX Employee set id = '0', name = 'Jay Miner'
> CREATE EDGE employedBy FROM (select from Employee where id = '0') TO
> (select from Company where name = 'Commodore')
>
> // QUERY ALL THE EMPLOYEES OF COMMODORE
> // ----
> SELECT expand( in('employedBy') ) FROM Company WHERE name = 'Commodore'
>
> // QUERY WHERE JAY IS WORKING
> // ----
> SELECT expand( out('employedBy') ) FROM Employee WHERE id = '0'
>
> Both query use indexes. To know more the shift between the relational
> model to the graph one look at:
> http://www.slideshare.net/lvca/why-relationships-are-cool-but-join-sucks-big-data-graphs-in-rome
>
>
>
> Best Regards,
>
> Luca Garulli
> Founder & CEO
> OrientDB <http://orientdb.com/>
>
>
> On 4 August 2015 at 20:00, Team Xcelerator Inc. <[email protected]
> <javascript:>> wrote:
>
>> I am trying to introduce Orient at work but running into a challenge with
>> indexes. They can only be created on class-level properties, which means
>> that linked child properties are not allowed. For example, say I had an
>> Employee class and Company class. The Employee class could have a LINK to
>> the Company class such as employedBy. Let's say Employee has an id
>> property and Company has a name property. Currently, you can't create
>> indexes that traverse links. I would love to create an index using the
>> following: CREATE INDEX Employee.idCompanyName ON Employee (id,
>> employedBy.name) NONUNIQUE
>>
>> If you try to create the index, it will fail because the employedBy.name
>> property does not directly exist within Employee. In order to get around
>> this, I would be forced to de-normalize and duplicate the data. That's a
>> maintenance risk and hassle. Have you considered allowing indexes on linked
>> child properties?
>>
>> Thanks and keep up the great work :)
>>
>> --
>>
>> ---
>> 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] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
---
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.
