Neo4j - метки против свойств vs отношения + node
Любое эмпирическое правило о том, где использовать метку vs node свойство vs relationship + node.
Давайте иметь пример, скажем, у меня есть магазин, и я хочу поместить свои продукты в neo4j. Их идентификатор является продуктом sku, и я также хочу, чтобы на них была категоризация, такая как для одежды, еды, электроники, и вы поняли эту идею. У меня будет бесплатный поиск на моем графике, так как пользователь может что-то искать, и я верну все, что связано с этой строкой поиска.
Было бы лучше использовать:
1) У меня есть node с sku 001
, и я помечаю его меткой Food
.
2) У меня есть node с sku 001
и имеет свойство на этом node, называемом category:"Food"
3) У меня есть node с sku 001
, и я создам еще один node для Food
и создаст отношение "category
", чтобы связать их.
Я читал, что если вы будете искать свойство, лучше как отношение + node, поскольку перемещение происходит намного быстрее, чем поиск свойств node.
ТИА
Ответы
Ответ 1
Следует ли использовать свойство, метку или node для категории, зависит от того, как вы будете запрашивать данные.
(я буду здесь считать, что у вас довольно небольшой, довольно фиксированный набор категорий.)
Используйте свойство, если вы не будете запрашивать по категориям, но просто нужно вернуть категорию node, которая была найдена другими способами. (Например: какова категория элемента с sku 001
?)
Используйте метку, если вам нужно запросить категорию. (Например: каковы все продукты стоимостью менее 10 долларов США?)
Используйте node, если вам нужно пройти категорию, не зная, что это такое. (Например: какие десять самых популярных элементов в той же категории, что выбрал пользователь?)
Ответ 2
Это сообщение в блоге также может быть полезно из-за содержащегося в нем эталона.
Я смоделировал связь "по-разному"...
- Использование определенного типа отношений
(node)-[:HAS_ADDRESS]->(address)
- Использование общего типа отношений, а затем фильтрация по конце node label
(node)-[:HAS]->(address:Address)
- Использование общего типа отношений, а затем фильтрация по свойству отношений
(node)-[:HAS {type:"address"}]->(address)
- Использование общего типа отношений, а затем фильтрация по контуру node Свойство
(node)-[:HAS]->(address {type: "address"})
<... >
Итак, в резюме... конкретные отношения #ftw!