Как реализован поиск в яндекс маркете и хранение данных?

Question

[searche]

К примеру, данные по товару хранятся в простом массиве, их два, с более востребованной информацией и всей информацией.

Как реализован поиск? По префикса, по переменным??

Мне кажется что есть еще одна таблица, в которой уже хранятся еще больше данных.. Что бы сделать просто mysql запрос, а не извращаться.
Может я ошибаюсь и они хранят все в одном массиве. Подскажите пожалуйста или в каком направлении искать? Я уже 16й день эту задачу пытаюсь решить, но что-то постоянно не то.
Вот нашел, но это не то. Самое странное что там не на js сделано, только запрос и ответ отсылается с помощью ajax.

Может я не догадываюсь, но ответ в name="manufacturers[]" value="2" Не прошу делать все за меня, а только подтолкнуть-подсказать, поправить если я не в том направлении иду.

таблица там точно большая и скорее всего разбита на 2, может на 3..

Comments

[FanatPHP]

По ссылке ад с sql инъекциями. Лучше бы её убрать

[searche]

FanatPHP: Это к примеру, mysqli вроде не должна пустить)

[FanatPHP]

mysqli - не волшебное заклинание, которое делает данные безопасными автоматически, просто фактом своего присутствия. "Не пускает" не библиотека которой ты пользуешься, та то КАК ты ей полльзуешься. По ссылке показано НЕПРАВИЛЬНОЕ использование, все в инъекциях.

[searche]

FanatPHP: Значит этот вариант отпадает. Спасибо)

Answer 1

[АртемЪ]

Данные хранятся не в массиве, а в базе данных.

Comments

[searche]

В массиве, а массив уже в базе, вот о чем я. А в остальном спорить не буду)

[АртемЪ]

В базе хранятся данные, а никак не массив.

[searche]

Артем: Я иногда в базе храню ответы json, забили)

Answer 2

[FanatPHP]

Вещи, которые тебе надо понять перед тем, как начинать что-то делать
1. То, как делает Яндекс - тебе абсолютно ни к чему.
2. Поиск и хранение - это разные вещи.
3. Хранение, с точки зрения выбранных тегов, можно решать двумя путями:
- Либо EAV - когда в таблице хранится идентификатор товара, идентификатор свойства, значение.
- Либо древовидная БД, типа Монги
4. Поиск, с точки зрения выбранных тегов - Сфинкс.

Но если у тебя товары хранятся в массивах, а не в БД, и удивлает отсутствие реализации на яваскрипте, то тебе пока рановато такими вещами заниматься. Для начала освой простую реляционную базу данных.

Comments

[searche]

Да я уже знаю и с финксом знаком не мало. Про массивы, нет данные разумеется хранятся в базе, я о другом, что все эти параметры заносится в массив и после уже записываются. Про EAV, можно повесится будет, если значений будет 100 и на каждое свой вариант? Должна быть альтернатива..

[searche]

Сфинкс на многое способен, он создан для любого поиска, в любом случаи быстрее него еще не чего нету. Скорее всего к дереву придется прибегнуть. И меня не товары, я взял яндекс за пример.

[FanatPHP]

searche: Значений будет значительно больше, чем 100. Именно поэтому EAV представляет собой прекрасный вариант. Особенно для начинающего, который даже вопрос по своей задаче сформулировать не может.

[FanatPHP]

searche: в данном случае речь не о скорости поиска а об использовании Сфинкса для поиска по параметрам. Но говорить о любых конкретных реализациях можно только если знать реальную задачу.

[searche]

FanatPHP: Да ладно, не каких других решений нету?
Можно подключить php, но он сразу загрузит сервак на 5% точно.
Не подскажешь что стоит почитать? Я раньше делал обычные таблицы, по принципу eav только меню категорий состоит, даже состояло.. По выборки я более менее знаю как писать условия, а вот хранения... только ответы json (можно сказать что это и есть массив)

Или может стоит пересмотреть реализацию? хотя нет, это единственно решение, спасибо!

[FanatPHP]

searche: пока ты не напишешь, какая задача стоит перед тобой, ничего конкретного ответить невозможно

[baracuda2]

Если взять во внимание его пример, то ему надо что-то подобное как
товар1 тут ты просто пишешь общее что может быть у всех
товар1.1 а тут уже то, что изменяется
товар1.2 тут тоже самое
товар1.3 как и тут
первое это id товара, вторая цифра как вариант, по мне идеально решение.

Я вот только не знаю что ты будешь делать с другими параметрами, которые будут в таблице в виде null
Вот пример, у вас есть таблица, как вы говорили у вас для каждой свои параметры, если я правильно понял, выглядит это так "Если я ошибаюсь поправите оба)"

id_категорий| имя
______________________
1			| телефоны
2			| одежда

id_товаров		| id_кат |имя 		 |камера|экран|обхват|размеры	  |итд
________________________________________________________________________________________
1				| 1		 |телефон 1  |8		|4.2  |null	 |142x50x20	  |итд
2				| 2		 |блузка     |null	|-    |52	 |я не знаю)       |итд
3				| 1		 |телефон 32 |2		|5.2  |null	 |180x60x2|итд


id_товара| имя версии|ip66|mp3|цвет|
___________________________________
1 		 |1			|1 	 |yes|#213
2 		 |1			|no	 |-  |#985
3 		 |2			|0 	 |1  |#854

Я вот не спец по mysql и не могу сказать, как скажет этот null или прочерк или пустое поле, когда вы будете заполнять эти поля, если не чего, то можно так и сделать. А если все же скажется, то надо подумать. В любом случаи вот 1я проблема, если категорий будет много, то и параметров тоже и если я правильно вас тогда понял, то к каждой категории будет свой конфиг с этими параметрами. В то время у вас будет 500 полей, но заполнятся будет лишь 1/7 в лучшем случаи. Я думаю что лучше пойти дашье и разбить их еще.. а то с каждой строчки будет записывать по 6/7 нулей а это лишний вес. FanatPHP поправишь, если я ошибаюсь. Ну и второе уже не такое серьезно, это запись параметром. "да может быть: да, тру, 1,ес итд.. с нет аналогично, я как-то с этим не сталкивался за 2 года, так что может и нет такой проблемы" Но где-то читал, при таковых условия создается дыра, вроде бы это про числа 1 и 0, не совету. Может меня снова кто-то поправит. Так-то надо думать о другом, ведь база очень быстрая, если все правильно сделано. Это не mysql3 волноваться надо в других местах, к примеру один запрос можно написать по разному, разница не большая будет, а вот скажется еще как.. Ну и конечно надо индексы ставить. Думаю что тут во всех случаях.. На 40 000 товаров вполне хватит 8гб озу + кэша гигов 10 и все, не тормозов не лагов

[baracuda2]

вот, к примеру когда пользователь рег. новую категорию, то там он должен выбрать параметры, которые больше подходят к это категории..
А потом просто сделать для каждой категории свою таблицу и в ней уже записывать параметры. Там тоже буду вылетать пустые ячейки, но уже меньше. Я просто гений)
Ну и оптимизировать можно на 3 уровня, легкая версия, полная, и для поиска.
В легкой только самое не обходимое, в полной, не.. это плохо.. Вообщем подумаете вечерком. А я буду думать над своим чпу)

[FanatPHP]

baracuda2: этот вопрос уже жеван-пережеван сто раз. И только ты кидаешься его исследовать с жаром неофита. Предложенный тобой вариант - самый кривой из возможных.

[baracuda2]

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

Answer 3

[xmoonlight]

id, parent_id, caption[varchar], value1(float), value2(float), value3(float), owner_id

c:"смартфон"->c:"nokia"->c:"камера"->c:"Mpx",value1:20 (4 записи)

можно все 1 таблицу, можно поделить так, как хотите. кортежи - останутся те же.
и таблица owner_id:
0:system
1:admin
2:user_1
3:user_2

Answer 4

[Aleksey Bernackiy]

Тут немного более подробно.