Я играю с neo4j, и мне было интересно, часто ли свойство type на узлах, указывающих, какой это тип узла? Я пробовал искать эту практику и видел, как некоторые люди использовали name для подобных целей, но мне было интересно, считается ли это хорошей практикой или индексы будут более практичным методом?
Примером может служить узел «Пользователь», который будет иметь тип: user, таким образом, если бы индекс был плохим, я мог бы выполнить сканирование всех узлов и найти типы user.
Правда, это зависит от вашего варианта использования. Если вы добавляете свойство типа, а затем хотите найти всех пользователей, то у вас могут возникнуть проблемы, поскольку вам нужно проверить это свойство на каждом узле, чтобы добраться до пользователей. В этом случае индекс, вероятно, будет лучше, но не в тех случаях, когда вам нужно запросить всех пользователей с условиями и отношениями, недоступными в индексе (если, конечно, ваш индекс не является источником «начала»). Если у вас есть графы, подобные моему, где тип отношения подразумевает два разных типа узлов, например A- (знает) - (B), а A или B могут быть пользователем или клиентом, то это не работает.
Таким образом, ваш вариант использования действительно важен - легко моделировать графики в целом, но важно «настроить» его в соответствии с вашим шаблоном использования.
Ярлыки были добавлены в neo4j 2.0. Они исправляют эту проблему.
Вы можете создавать узлы с метками:
CREATE (me:American {name: "Emil"}) RETURN me;
Вы можете сопоставить по этикеткам:
MATCH (n:American)
WHERE n.name = 'Emil'
RETURN n
Вы можете установить любое количество меток на узле:
MATCH (n)
WHERE n.name='Emil'
SET n :Swedish:Bossman
RETURN n
Вы можете удалить любое количество меток на узле:
MATCH (n { name: 'Emil' })
REMOVE n:Swedish
Так далее...
ИМХО вам не нужно помещать свойство типа в узел. Вместо этого распространенным способом ссылки на все узлы определенного «типа» является подключение всех пользовательских узлов к узлу, называемому, возможно, «Пользователи». Таким образом, начиная с узла Users, вы можете очень легко найти все пользовательские узлы. Сам узел «Пользователи» можно проиндексировать, чтобы его было легко найти, или он может быть подключен к ссылочному узлу.
Я думаю, это действительно ваше дело. Некоторым людям нравятся атрибуты индексированного типа, но я считаю, что они наиболее полезны, когда у вас есть другие индексированные атрибуты, чтобы сузить количество совпадений индекса (например, поиск всех пользователей старше 21 года).
Тем не менее, как отмечает @Luanne, большинство из нас сначала пытается решить проблему в графе. Другой способ сделать это (и, на мой взгляд, более естественный) - использовать тип отношения для вывода практического типа узла, например «A - (знает) -> B», поэтому A должен быть пользователем или каким-либо другим вещь, которая может «знать», а B должен быть другим пользователем, темой или каким-то другим объектом, который может быть «известен».
Для клиентских API-интерфейсов моделирование типа элемента как свойства упрощает создание экземпляра нужного объекта домена в коде на стороне клиента, поэтому я всегда включаю свойство типа для каждого узла / вершины.
Для этого обычно используется имя переменной типа "type", но в некоторых языках, таких как Python, "type" является зарезервированным словом, поэтому я использую "element_type" в Bulbs (http://bulbflow.com/quickstart/#models).
Это не требуется для ребер / отношений, потому что они уже содержат тип (метку) - обратите внимание, что Neo4j также использует ключевое слово «тип» вместо метки для отношений.
Я бы сказал, это обычная практика. Например, именно так Spring Data Neo4j знает, к какому типу сущности относится определенный узел. Каждый узел имеет свойство type, которое содержит полное имя класса объекта. Эти свойства автоматически индексируются в индексе "типы", поэтому узлы можно искать очень быстро. Вы можете реализовать свой вариант использования именно так.
Ярлыки были недавно добавлены в Neo4j 2.0 (http://docs.neo4j.org/chunked/milestone/graphdb-neo4j-labels.html). В настоящее время они все еще находятся в стадии разработки, но они решают именно эту проблему.
