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

Question

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

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

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

Вопрос

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

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

Answer 1

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

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

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

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

Answer 4

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

Фасетный поиск в основном означает фильтрацию по определенному качеству «предмета». Это качество или свойство могут относиться к категории, к которой оно относится, или к чему-то еще.

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

[    User   ]
| name char |
| age  int  |

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

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

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