Как правильно реализовать каталог с параметрическим поиском

[craz]

Я апнул свой комент после http://www.ibm.com/developerworks/ru/library/os-sphinx/

Опишу "Один фиг": Есть что-то большое и не поворотливое, созданное только ради ублажения хотелок в 95% или ради того чтобы не заниматься генерацией таблиц связей на лету 5%, то есть архитектурой бд. К этому большому мы прикручиваем сфинкс дабы снизить затраты на поиск и выборку - это нормально?

И если я в чем то не прав, почему сразу менторский тон и тычешь меня в санные тряпки?) Будь проще, я ж не полный нуб, умею менять свое мнение.

 

[Фанат]

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

Я апнул свой комент после url

- это именно то, о чем я говорил.
Ты в смысл "тыканья" не пробовал вникать? Или воспринял только тон? А там главное - смысл. Причём посыл очень простой, примитивный: "не щупал - будь скромнее в суждениях". Что в этом совете такого оскорбительного?
Ты повторяешь сейчас ошибку всех ламеров - пытаясь оправдаться, ты, на самом деле, ещё больше закапываешься.

Сфинкс нужен не только для прикручивания к большому и неповоротливому.
По многобазе у нас поиск тоже сфинксом. И по реляционной мускулевской базе - сфинксом.
Потому что сфинкс - это просто поисковый движок, его всё равно, к чему прикручивать. Он иррелевантен обсуждаемому топику. Так что ты уже два раза в лужу дунул - сначала сказав про "ещё одно тормозное", а потом про спасителя большого и неповоротливого. пора уже остановиться

 

[craz]

пост

Твое типичное поведение, ты с обсуждаемого ушел в сторону другого. Я рад что сфинкс такая классная штука, только причем он тут?

 

[флоппик]

только причем он тут?

каталог с параметрическим поиском

Фанат прав, не надо оправдываться. Это сразу видно со стороны, и выглядит жалко. Будь лучше Фаната, признай, что неправ — это важный шаг к профессиональному развитию — видеть свои косяки.

 

[craz]

На каждую запись по таблице и сфинксом поверху прикрыть и все будет хорошо.

А свою неправоту я признал в том же сообщении в котором не прав был.
Не понял не твоих, не его претензий.

 

[флоппик]

Не понял не твоих, не его претензий.

У меня нету к тебе претензий. Мне похер, если честно. Я лишь даю совет: что бы развиваться, нужно признавать, где ты не прав, и ты будешь знать, что это место можно улучшить в себе. Что ты с этим советом сделаешь — примешь к сведению или обидишься на него, — мне не особо важно.

 

[craz]

У меня нету к тебе претензий. Мне похер, если честно. Я лишь даю совет: что бы развиваться, нужно признавать, где ты не прав, и ты будешь знать, что это место можно улучшить в себе. Что ты с этим советом сделаешь — примешь к сведению или обидишься на него, — мне не особо важно.

как я не прав, как не прав... - развиваюсь?)
Сфинкс мне никогда не был нужен, признаю что руками его не трогал, что дает представляю только исходя из статей. - вот поперло развитие!

Если серьезно то исходя из того, что смутно представлял себе: есть Mysql(это программа в памяти, которая жрет процессорное время) - работает с какой-то скоростью. И есть еще одна программа Sphinx(тоже программа) - работает с какой-то скоростью. v1+v2 = V(если это вектора).
Но теперь я знаю что это не так. И есть только скорость v2 Sphinxa

 

[fixxxer]

Для начала нужно ответить на вопрос, почему бы не сделать плоские таблицы в mysql, и почему вместо такого простого и очевидного решения суют всякие сфинксы.
На уровне алгоритмов, а не "слышал что работает быстрее".
А потом уже рассуждать.

 

[Beavis]

Так что, какой в итоге идеальный вариант?) Делать для каждой категории свою таблицу, или взять nosql субд?

 

[craz]

Для начала нужно ответить на вопрос, почему бы не сделать плоские таблицы в mysql, и почему вместо такого простого и очевидного решения суют всякие сфинксы.
На уровне алгоритмов, а не "слышал что работает быстрее".
А потом уже рассуждать.

Согласен полностью.

Так что, какой в итоге идеальный вариант?) Делать для каждой категории свою таблицу, или взять nosql субд?

Мое глубокое имхо
а) нужна денормализация
б) в mysql можно достигнуть только через EAV(так?) - этот паттерн/антипаттерн обеспечивает всем понятную модель предоставления данных
в) в nosql этого можно достигнуть проще
г) для Mysql понадобиться что-то еще

Наверное nosql решение хорошее.

 

[radioheaded]

Начни делать уже что-нибудь.
Начни спотыкаться о грабли.
Анализируй то, что получается, недостатки функционала, неудобства.
Изучи возможности других решений и то, насколько они покрывают полученные при анализе недостатки, неудобства; какие удобства, преимущества при этом теряются.
Будь мужиком, прими решение на основании всего этого и либо продолжай делать, либо начни делать заново при помощи новых выбранных инструментов.

 

[Фанат]

Делать для каждой категории свою таблицу

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

Плюс, по сути, любой каталог товаров имеет древовидную, а не линейную структуру: скажем, набор таких характеристик, как поддерживаемые стандарты связи. И это практически в каждом параметре!

Именно поэтому древовидная монга, при всех своих недостатках, гораздо лучше отображает в виртуальности такое понятие реальной жизни, как "каталог товаров"

 

[Фанат]

Согласен полностью.

С чем ты согласен-то?
Ты хоть понял, о чем там речь?

 

[Фанат]

Начни делать уже что-нибудь.

В данном конкретном случае цена ошибки довольно высока, как и затраты на

начни делать заново при помощи новых выбранных инструментов

 

[Фанат]

а) нужна денормализация

почему ты все время повторяешь эту денормализацию, как заклинание? что ты конкретно имеешь ввиду? Для решения какой конкретной задачи тебе нужна денормализация? Какие конкретно данные собрался денормализовывать?

б) в mysql можно достигнуть только через EAV(так?) - этот паттерн/антипаттерн обеспечивает всем понятную модель предоставления данных

Ты эту модель в действии видел? можешь сейчас привести код, который выводит все характеристики определенного телефона? Сколько SQL запросов тебе для этого понадобится?

г) для Mysql понадобиться что-то еще

отличный пункт.

 

[Gas]

Ты эту модель в действии видел? можешь сейчас привести код, который выводит все характеристики определенного телефона? Сколько SQL запросов тебе для этого понадобится?

не защищаю EAV, но не вижу смертельных проблем выбрать характеристики товара(ов) - одним запросом достаются все характеристики. Другое дело что если их нужно получить для нескольких товаров, то нужно пройтись по всем полученным свойстам и привязать к нужному товару, так как вываливается plain-список этих свойств. Хотя, независимо от того, для одного товара или нескольких свойства достаются, всё равно приходится циклом бежать по ним и формировать из сырых данных уже нормальную структуру - в зависимости от типа свойства, доставать значение из соответствующего поля.

что касается mongo, да, она выглядит предпочтительней для хранения подобных структур.
но там тоже есть свои ньюансы - если не ошибаюсь, то всё ещё нет транзакций, которые очень часто и нужны как раз для eCommerce решений.

 

[флоппик]

но там тоже есть свои ньюансы - если не ошибаюсь, то всё ещё нет транзакций, которые очень часто и нужны как раз для eCommerce решений.

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

 

[Gas]

флоппик
так вот хотелось бы избежать необходимости плодить сущности, эх, нет пока идеала )

кстати по поводу одного запроса - может и погарячился, щас я погляжу на один из старых проектов с eav и проверю, может быть и не один запрос, так как там свойства не просто какое-то значение, а значения и из динамических справочников + свойства объеденены в группы, которые тоже нужно показывать.

 

[Фанат]

кстати по поводу одного запроса - может и погарячился, щас я погляжу на один из старых проектов с eav и проверю, может быть и не один запрос, так как там свойства не просто какое-то значение, а значения и из динамических справочников + свойства объеденены в группы, которые тоже нужно показывать.

во-во!
это уже ближе к реальности

 

[флоппик]

флоппик
кстати по поводу одного запроса - может и погарячился, щас я погляжу на один из старых проектов с eav и проверю, может быть и не один запрос, так как там свойства не просто какое-то значение, а значения и из динамических справочников + свойства объеденены в группы, которые тоже нужно показывать.

Количество запросов не критерий — критерий скорее их сложность. Толку-то если запрос один, но выполняется секунд 20 ?