OrientDB — простой пример работы с графами

Решил написать статью, для новичков, т.к в начале сложнее всего.

И для начала, кому интересно:

Ну а мы давайте приступим и первым делом запустим 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) — это разбиение больших таблиц на логические части по выбранным критериям.

Удачного изучения.

Оцени публикацию:
  • 3,15
Оценили человек: 3
Теги : OrientDB

Похожие статьи:

Справочники и учебники:


Предложения и пожелания:
Ваше имя:
Ваш E-mail:
Сколько будет Οдин + Τри
Главная
X

Новые заметки:

Про что мы забываем когда делаем оценку задачи по времени

Список вопросов для собеседования разработчика по телефону

Symfony2 авторизация без Doctrine2 для чайника

Phpstorm7 LiveEdit

Жесткий хабр или не хабр, тогда кто?

Яндекс.Деньги мошенничество

Как узнать какие страницы в поиске яндекса или это секрет

Последние комменты:

Yapro CMS:

Здравствуйте, Гость | Войти | Регистрация | Карта сайта | RSS ленты | Ошибка в тексте? Выделите её мышкой и нажмите: Ctrl + Enter

youtube.com/watch?v=7hFivbgIEqk

При полном или частичном использовании материалов данного сайта, ссылка на сайт "yapro.ru" обязательна как на источник информации.
Автоматический импорт материалов и информации с сайта запрещен.
Copyrights © 2007 - 2018 YaPro.Ru

Главная » Веб-мастеру » MySQL »