Sorry, I don't have any tutorial
Maybe you can start from here:
http://orientdb.com/docs/3.0.x/datamodeling/Concepts.html
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 a.id as "Costumer Identifier", c.name as "Work Town" from costumers
a inner join company b on a.work_for = b.id inner join towns c on b.town =
c.id where a.name = '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').town.name 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').town.name as "Work Town"
from #35:35574535
Il giorno mar 18 giu 2019 alle ore 12:58 GraphPerson <[email protected]>
ha scritto:
> 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.
> Thanks
>
> On Tuesday, June 18, 2019 at 1:08:28 PM UTC+3, Gianluigi Belli wrote:
>>
>> 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.
>>
>> On Monday, June 17, 2019 at 4:05:11 PM UTC+2, GraphPerson wrote:
>>>
>>> Hi,
>>> 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.
>>> Thanks
>>>
>> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "OrientDB" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/orient-database/LulmMcrUE_w/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/orient-database/0d709c73-f762-4d5c-87c1-f56adb38b4b6%40googlegroups.com
> <https://groups.google.com/d/msgid/orient-database/0d709c73-f762-4d5c-87c1-f56adb38b4b6%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/orient-database/CAFhSsc3VuECV%2B5QkpALVk4Ut1xQQD%3DMnttYky-532J4e5FdMWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
