Алгоритм поиска товаров

[victoriaff]

Привет всем.

После напрасных поисков в Интернете, я решил обратиться на форум, потому-что ответа я не нашел.

Вопрос в чем: решил я сделать каталог электроники, например возьмем мониторы (http://www.citilink.ru/catalog/monitors/), и столкнулся с проблемой организации поиска по каталогу.

А именно не совсем понятны следующие моменты:
1) Чтобы запросы к БД исполнялись быстро, нужно проиндексировать все товары и результаты хранить в базе, и при указании различный критериев поиска, выводить уже готовый результат. Методом перебора при указании уже от 1 до 20 критериев, количество вариантов сотня тысяч. А еще результаты нужно где-то хранить. А я видел 50 и больше критериев поиска, как быть, в каком виде должны сохранятся результаты индексирования ?

2) Какая БД и какие сервера используются для создания такого каталога ?

3) Буду благодарен за любую полезную инфу. Или может я не совсем правильно понимаю весь механизм каталога ?

 

[AmdY]

.... действительно, не то

 

[Koc]

он же не о том спрашивает. Ем нужна layered navigation как в Magento, Сфинкс он же для полтнотекстового поиска?

 

[Koc]

по сабжу http://www.slideshare.net/spf13/mongodb-and-ecommerce-a-perfect-combination

 

[Mols]

1) Чтобы запросы к БД исполнялись быстро, нужно проиндексировать все товары и результаты хранить в базе, и при указании различный критериев поиска, выводить уже готовый результат.

Это не совсем так.
Если в запросе можно использовать индекс даже на 1-2 поля но с действительно хорошей селективностью то кеш результатов может и не потребоваться вовсе.
Вот например мониторы о которых Вы говорите. Пусть их будет представлено скажем 1 000. Даже если у всей тысячи проверить все параметры, то это не так уж и сложно для базы.
Как минимум тип устройства человек знает всегда.
То есть что ему надо клавиатура, мышь или монитор.
И это уже само по себе даст неплохую селективность ведь так?
Надо подумать (только без фанатизма) на чем Вы ещё гарантированно можете получить детализацию (например если это каталог на продажу, то есть ли оно на складе или нет).
Дальше смотреть на практике, где будет тормозить.
И если будет - тогда смотреть, что можно сделать.

З.Ы.
Только это нифига не теория программирования

Добавлено 15.02.2011 12:27
Похоже ТС - очередной гений СЕО.

 

[victoriaff]

Я тут подумал, кое с кем пообщался, и остановился на следующем варианте:

1) Использовать БД MySQL. Тип таблиц MyISAM.
2) Для каждой категории товара отдельная таблица в БД
3) Продуманно построить индексы для таблиц БД
4) Все запросы к БД строить на лету. Хотя их будет достаточно много (10-30), но из-за малого размера таблиц, БД не должна тормозить. А если вдруг и будет, перейду на серъезное железо.

Какие плюсы:
1) Не нужно будет постоянно переиндексировать каталог при добавлении нового товара или редактировании.
2) Проще в обслуживании (чем проще, тем лучше)

Всем спасибо за помощь.

З.Ы.
А почему это не теория программирования ?

 

[autosoft]

2) Для каждой категории товара отдельная таблица в БД

Про теорию нормализации отношений в реляционных базах данных хоть что-то знаем?

4) Все запросы к БД строить на лету. Хотя их будет достаточно много (10-30), но из-за малого размера таблиц, БД не должна тормозить. А если вдруг и будет, перейду на серъезное железо.

Без грамотной организации базы данных - это не поможет.

1) Не нужно будет постоянно переиндексировать каталог при добавлении нового товара или редактировании.

???

А почему это не теория программирования ?

Потому что вопрос из области практики.

 

[dimagolov]

Я тут подумал, кое с кем пообщался, и остановился на следующем варианте:

1) Использовать БД MySQL. Тип таблиц MyISAM.

худший тип таблиц в мускле

2) Для каждой категории товара отдельная таблица в БД

никому не нужная глупость

3) Продуманно построить индексы для таблиц БД

желание не плохое само по себе, в этом как бы и заключается разработка и оптимизация структуры БД в значительной степени, но с учетом №4 нереальное

4) Все запросы к БД строить на лету. Хотя их будет достаточно много (10-30), но из-за малого размера таблиц, БД не должна тормозить. А если вдруг и будет, перейду на серъезное железо.

Какие плюсы:
1) Не нужно будет постоянно переиндексировать каталог при добавлении нового товара или редактировании.
2) Проще в обслуживании (чем проще, тем лучше)

А вот тут Остапа понесло. Основной момент в том, что запросы тормозят не от того, были они записаны заранее или формируются из данных перед исполнением (вообще ВСЕ запросы формируются перед исполнением, по крайней мере параметры подставляются), а тормозят от того, на сколько сложно для БД отобрать нужные данные. Но невозможно понять, что на это влияет, без каких-то базовых знания по РСУБД и опыта их использования, отсутствие которых тут продемонстрировано.

 

[Koc]

никому не нужная глупость

http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back 29 страница

 

[symfo]

victoriaff, вам не о скорости сейчас нужно заботиться, а о правильной организации данных. В 2005 я писал сложную систему подбора и сравнения товаров на PHP4+MySQL.
Подбор товаров (электронника) по множеству параметров (до 150). Все товары делятся на классы и параметры товаров каждого класса хранится в отдельной таблице. Так же параметры делятся на группы. Так же имеются служебные таблицы, связывающие все в одну систему.
Товаров в базе было около 7000. Все работало вполне быстро. Сервер выделенный.
Если реализовывать такое средствами ORM+APC, то должно работать еще быстрее.

 

[craz]

victoriaff, вам не о скорости сейчас нужно заботиться, а о правильной организации данных. В 2005 я писал сложную систему подбора и сравнения товаров на PHP4+MySQL.
Подбор товаров (электронника) по множеству параметров (до 150). Все товары делятся на классы и параметры товаров каждого класса хранится в отдельной таблице. Так же параметры делятся на группы. Так же имеются служебные таблицы, связывающие все в одну систему.
Товаров в базе было около 7000. Все работало вполне быстро. Сервер выделенный.
Если реализовывать такое средствами ORM+APC, то должно работать еще быстрее.

вы на даты сообщений смотрите - не стоит заниматься некропостингом

 

[symfo]

Хммм, вроде бы не так много времени прошло, но если здесь это считается некропостингом, то более не буду .

 

[craz]

да это большой форум и на нем 600к сообщений, если не решилось за 1-2 дня значит эта тема не будет решена никогда.