Решил написать статью, для новичков, т.к в начале сложнее всего.
И для начала, кому интересно:
- немного теории
- немного практики с помощью php-скрипта (для выполнения выборки данных)
Ну а мы давайте приступим и первым делом запустим orientDB-сервер:
/programs/orientDB/bin/server.sh
Во вторых зайдем в orientDB-консоль:
/programs/orientDB/bin/console.sh
В третьих, нам нужно узнать рутовый пароль, а прописан он в файле:
/config/orientdb-server-config.xml
поищите строчку с "password" и все сразу поймете.
Зная пароль, можно создать базу данных:
orientdb> create database remote:localhost/people root PASWORD local
напомню синтаксис таков:
create database <database-url> <user> <password> <storage-type> [<db-type>]
Посмотрим информацию о нашей базе данных:
orientdb {people}> info
и видим, что при создании появляются стандартные классы, кластеры и индексы.
Создадим класс персон ( Person ):
create class Person extends V
обратите внимание, мы создали класс типа Vertex (вершина)
Добавим в класс строковое свойство name
create property Person.name string
Создадим две вершины:
create vertex Person set name='Joanie'
create vertex Person set name='Chachie'
В статье которую я собирался перевести, автор создает класс в котором якобы будет указывать связи между этими персонами
create class Loves extends E
на самом деле этот класс не играет никакой роли и его создавать не нужно (пока не нужно).
Добавим одну связь между персонами:
create edge Loves from #11:1 to #11:0
обратите внимание, мы создали связь типа EDGE (ребро).
Итак, мы связали двух персон, проверим нашу работу:
orientdb {people}> select from Person
----+-----+-------+--------+---------
# |@RID |name |in_Loves|out_Loves
----+-----+-------+--------+---------
0 |#11:0|Joanie |#11:1 |null
1 |#11:1|Chachie|null |#11:0
----+-----+-------+--------+---------
Заметьте, в классе Person появилось 2 поля:
- in_Loves
- out_Loves
эти поля создаются автоматически, и отказаться от их создания не получится, да и не нужно, т.к. в этих полях можно увидеть связь наших персон ( @RID ), но что это нам дает? А дает это нам то, что к этим полям можно обращаться как к объектам, например если написать запрос:
orientdb {people}> select name, in_Loves.name as in, out_Loves.name as out from Person
----+-----+-------+-------+------
# |@RID |name |in |out
----+-----+-------+-------+------
0 |#-2:1|Joanie |Chachie|null
1 |#-2:2|Chachie|null |Joanie
----+-----+-------+-------+------
то мы получим не @RID связей, а данные связанных объектов.
Обратите внимание, т.к. наш класс Person наследуется от класса V, то все данные связи так же будут существовать и в классе V:
orientdb {people}> select from V
----+-----+-------+--------+---------
# |@RID |name |in_Loves|out_Loves
----+-----+-------+--------+---------
5 |#11:0|Joanie |#11:1 |null
6 |#11:1|Chachie|null |#11:0
----+-----+-------+--------+---------
Кто-то, кто немного изучал OrientDB, может спросить, а как же E (EDGE), почему ребро не прописалась туда?
Все очень просто, чтобы связь прописалась в E, ребру нужно давать имя. Т.е. мы писали:
create edge Loves from #11:1 to #11:0
а нужно было писать:
create edge from #11:1 to #11:0 set MyFieldName = 1
кроме того, можно создать класс Loves (см. выше, мы его пропустили) и создавая связь указывать название класса:
create edge Loves from #11:1 to #11:0 set MyFieldName = 1
таким образом, благодаря указанию имен полей (MyFieldName) мы можем разграничивать виды связей (в одном классе), а благодаря указанию имени класса, можно дополнительно разграничивать виды связей по классам. Однако, в классе Е всегда будут указаны все виды связей, т.к. именно от этого класса мы экстендимся (обратите внимание на то, как мы создавали класс Loves).
Некоторые из Вас скажут: а зачем мне экстендится от класса E, если все равно все данные попадают туда?
Я тоже задался этим вопросом и автор OrientDB мне ответил так: плюс в том, что OrientDB лучше партицируется используя графы, и конечно это влияет на скорость выборки данных.
Напомню, что партиционирование (partitioning) — это разбиение больших таблиц на логические части по выбранным критериям.
Удачного изучения.
