Can Orien DB be used for style type of apps?

Skip to first unread message


Jun 17, 2019, 10:05:11 AM6/17/19
to OrientDB
Can Orien DB be used for style type of apps such as CRM?
Does anybody use it for that kind of a task?
I believe there are disadvantages using it like that. it was probably designed for relation first query and if you ask information like "select from customers where name like 'blabla'" you probably pay a price  in performence.

Gianluigi Belli

Jun 18, 2019, 6:08:28 AM6/18/19
to OrientDB
Why? You can associate an index to the property name.
You can also create lucene indexes for more complex and fast text-based searches.
You can certainly use it for CRM with no concern. Nevertheless, as it's required for any system, you have to work on the architecture of your db in advance. So it's essential to start to think of graphs, vertexes, arcs and classes, instead of tables, tuples and joins. This is the most significant effort. You don't make cartesian products; you traverse paths on nodes and nested documents.
Having the SQL can make it easier to start writing queries, but it is of no help in the process to change perspective.


Jun 18, 2019, 6:58:01 AM6/18/19
to OrientDB
Thank you. Do you have a tutorial of how to take classic sql db and migrate it to orient? I don't need a technical tutorial, more of a conceptual one, how old sql db will look like in orient db.

Gianluigi Belli

Jun 19, 2019, 12:56:29 AM6/19/19
to OrientDB
Sorry, I don't have any tutorial
Maybe you can start from here:

Just remember there is no join operation. This is the most significant difference between a relational dbms and a NoSQL dbms.
A relational query like:
select as "Costumer Identifier", as "Work Town" from costumers a inner join company b on a.work_for = inner join towns c on = where = 'Frank' and a.surname = 'Fedora'
in orientdb could be something like (depends on how you designed your database):
select id as "Costumer Identifier", out('work_at') as "Work Town" from costumers where [name,surname] lucene 'Frank Fedora'

In the relational case it involves 3 tables, 3 joins, 4 indexes. The complexity depends on how many records you have in your 3 tables. The mere they are, the slower your query will be.
In the orientdb query, there are 3 classes, an index and 0 joins. That it makes this one much more computationally efficient. Let say the costumer work for 4 companies, it reads exactly 1+4+4 documents. If you already have the rid of the costumer, the query can be run without any index at all, and it still reading exactly 9 documents. There is no dependency by how many total documents you have in your classes.

If you have the rid (eg. #35:35574535) the query will became:
select id as "Costumer Identifier", out('work_at') as "Work Town" from #35:35574535


You received this message because you are subscribed to a topic in the Google Groups "OrientDB" group.
To unsubscribe from this topic, visit
To unsubscribe from this group and all its topics, send an email to
To view this discussion on the web visit
For more options, visit
Reply all
Reply to author
0 new messages