Мы все знаем, что в Фейсбуке есть поиск по графику. Пользователи могут искать людей, которые любят кататься на велосипеде и родом из Лондона, например, друзей друзей, которые любят йогу, или фотографий друзей или парней с определенного месяца или года.
Все эти данные извлекаются из одного поискового ввода без полей фильтра.
Я пытаюсь начать с чего-то похожего на PHP, но не могу точно сказать, как это можно реализовать.
Мне было интересно, применяется ли это только через определенный подход к проектированию базы данных (простая RDBMS) … или это своего рода структуры узлов графа, которые логически связаны с таблицами базы данных с ключевыми словами … или смесью RDBMS и NOSQL. .. или любой другой подход. Что касается самого ввода текста, должен быть какой-то анализ и сопоставление с конкретными ключевыми словами, чтобы получить релевантность данных и направить их на правильное выполнение запроса.
Как лучше всего выполнять поиск по php-графику (или, по крайней мере, что-то похожее) на моем веб-сайте, где у меня есть нечто похожее на систему розничной электронной коммерции с сгруппированными релевантными данными?
Вы можете решить для каждого из ваших примеров отдельно, но это может оказаться утомительным, и вы, скорее всего, столкнетесь с проблемой производительности.
Люди, которые любят кататься на велосипеде и из Лондона (SQL)
SELECT users.id FROM users, posts, topics, locations WHERE posts.topic_id = topics.id AND users.id = posts.author_id AND users.location_id = locations.id AND locations.city = 'London' AND topics.name = 'cycling' GROUP BY users.id ORDER BY COUNT(posts.id) DESC
(используя действительно свободное определение «любить ездить на велосипеде» и «быть из Лондона»)
Реляционные базы данных не обрабатывают много соединений особенно изящно. Ваша производительность будет страдать под нагрузкой или с большим набором данных.
Однако в базе данных графиков (например, Neo4J или TitanDB) вы можете проследить граф связанных сущностей и собрать соответствующие узлы сущностей в более общей форме, в среде, оптимизированной для обслуживания тех вариантов использования, о которых вы думаете.
Тот же запрос (Cypher — Neo4J)
MATCH (topic:Topics {name:'cycling'}) <-[:POST_TOPIC]-(post:Posts) -[:AUTHORED_BY]->(user:Users) WHERE user-[:RESIDENT_OF]->(location:Location {city:'London'}) RETURN user.id AS user_id, count(post) AS post_count ORDER BY post_count DESC
Они также могут быть выражены как обходы Гремлин (для Титана и других графических БД), но они начинают становиться довольно многословными и их трудно расшифровать.
Существуют общие способы приблизиться к тому, что вы описываете, с помощью релевантности поиска графиков в стиле Facebook. В вашем случае это звучит так, как будто вы, вероятно, хотите персонализированный поиск, например все связанные вершины в пределах нескольких степеней разделения искателя (используя любые отношения ребер: местоположение, интересы, друзья и т. д.).
Если вы не можете легко перечислить все варианты использования, которые вы хотите создать сегодня, вы, вероятно, будете более довольны графической базой данных, поэтому вы можете экспериментировать со своими идеями и запускать их в производство без необходимости сокращать углы по соображениям производительности.
Других решений пока нет …