Структура базы данных для факсимильного поиска

Question

Я создаю сайт электронной коммерции, который должен иметь фасетный инструмент поиска, чтобы клиенты могли сузить поиск товара по категориям и классификациям в том же стиле, что и ebuyer.com и Newegg.com (см. Меню слева) ,

Первоначально я нырнул прямо в разработку базы данных, которая оказалась похожей на структуру EAV (я не знал, что это было в то время), это изначально казалось идеальным, поскольку я мог создавать неограниченные категории, подкатегории и другие классификации продуктов (например, цвет, размер, получатель), которые клиенты могут использовать для поиска определенных продуктов. Однако, когда я начал создавать SQL-запросы с использованием условий AND, я понял, как обычные простые запросы стали намного длиннее и сложными для записи.

Проведя несколько часов, просматривая различные сообщения о SO и статьях в Google, я понял, что кошмар, который будет впереди, если я продолжу этот метод.

Вопрос

Как бы сайты, как ebuyer.com и Newegg.com разработали свой граненый поиск?

Я пропустил альтернативный метод, или они просто пошли вперед с структурой EAV? Я стараюсь избегать таких корпоративных решений, как Lucene/Solr.

Answer 1

Хорошо, почему вы называете решение Lucene/Solr entreprise мудрым ... кажется, идеально подходит вам, на мой взгляд.

Answer 2

Я не знаю, как они это делают, но вы можете добиться этого, выполнив:

CREATE TABLE product_facets (
    product_id INTEGER NOT NULL, 
    facet VARCHAR(100) NOT NULL, 
    facet_value varchar(255) NOT NULL, 
    PRIMARY KEY (product_id,facet,facet_value), 
    KEY (facet,facet_value) 
); 

INSERT INTO product_facets VALUES (1, 'COLOR', 'Red'); 
INSERT INTO product_facets VALUES (1, 'PRICE_RANGE', 'Less than 200'); 

INSERT INTO product_facets VALUES (2, 'COLOR', 'Green'); 
INSERT INTO product_facets VALUES (2, 'PRICE_RANGE', 'From $200 to $500'); 

INSERT INTO product_facets VALUES (2, 'COLOR', 'Blue'); 
INSERT INTO product_facets VALUES (3, 'PRICE_RANGE', 'More than $1000'); 

SELECT facet, facet_value, count(*) 
FROM product_facets f 
INNER JOIN products p ON p.product_id = f.product_id 
GROUP BY facet, facet_value; 

фаска не должен быть VARCHAR. Это может быть простой INTEGER, поскольку ваше приложение знает, что это значит.

Answer 3

Я думаю, что вы смешиваете разные концепции (что, в свою очередь, может затруднить поиск решения).

Гранитированный поиск означает в основном фильтрация определенного качества «товар». Это качество или свойство может быть категорией, в которой она находится, или это может быть что-то другое.

Вы могли бы граненый поиск пользователей, где вы фильтровать по их возрасту, к примеру

[ User ] 
| name char | 
| age int | 

Как настроить Solr (или Сфинкс), чтобы получить конечный результат может отличаться, но это не имеет никакого влияния на вашей модели данных.

Я бы начал с концептуализации/моделирования того, что вы пытаетесь представлять/хранить в базе данных. Как вы показываете его или ищете, он приходит позже.

Без дополнительной информации, ваш вопрос о том, как другие сайты designed their faceted search является слишком широким и в то же время очень простым: вам просто нужно сгенерировать различные грани, основанные на различных свойствах продуктов; но вы также, похоже, хотите знать, как они смоделировали свою базу данных для хранения информации.

Answer 4

http://wiki.apache.org/solr/PublicServers

Ebuyer использует Solr и по уважительной причине, вы рискуете изобретать колесо.