Форум PHP

Всем привет. У меня такая проблема: на сайте есть поиск по параметрам, например, по цвету, весу, размеру и т.д. Всего пораметров поиска более двадцати. Как мне передать то, что выбрал посетитель на другие страницу (чтобы результаты поиска сохранились на форме) без учета GET параметров и, возможно, сессий? Просто хочу, чтобы у меня был короткий ЮРЛ, а не километровый. Сессии тоже не хочу, так как мне важно, чтобы пользователь мог передать ссылку другому человеку без потери результатов своего поиска.

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

сессия тут и не подойдет
просто сохраняйте результат в БД, и передавайте id строки

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

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

строк, а не столбцов.
строка одна на каждый поиск. А таких поисков может быть 10000 в день. Каждый раз делать запрос к БД - это не рентабельно. Вот смотрите: зашел Вася на сайт, поискал. Это инсерт. Потом еще раз поискал. Это апдейт. Потом еще поискал Х раз. Это еще Х раз апдейт. Нашел что-то. Перешел на другую страницу. Это уже селект. На MySQL это немного нерентабельно, потому что таких Васей могут быть 10000.

вы за советом пришли или мозг потрахать?
про "каждый раз запрос к БД" - это уже оставьте кешированию на уровне MySQL
и как только Васей будет 10000 посмотрите на нагрузку БД
а пока подозреваю Васей 0
__
вообще делайте что считаете нужным, мне все равно

я за советом пришел. Но MySQL не вариант.

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

смешно, да

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

Хорошо, тогда проведите тесты, что будет быстрее работать, выборка из БД по айди или file_get_content одной строки одного файла из файловой системы линукса, что будет быстрее, update/insert БД или запись строки в один файл? Учтите разные нагрузки на БД, совокупность выборки/вставки данных с другими запросами, другие условия, о которых можно погуглить.

Мне вот интересно, что будет быстрее, noSql БД или файловая система.

файлы - это тупое хранение, в БД возможен анализ и обработка

так мне не нужен анализ и обработка. тупо хранить в одном файле строку в json формате. Какая обработка-то?

так мне не нужен анализ и обработка
это уже не мои проблемы, но сильно рекомендую хоть изредка заглядывать в будущее

Хорошо, раз вы специалист, то объясните мне))

плохо знаком с nosql, но думаю зависеть будет от оптимизации таблиц. обычно самая затратная операция это подключение к бд. если это не единственная причина, из-за которой используется бд в проекте, то не вижу смысла использовать файлы. плюс опять же, есть тот же memcached. я вообще сомневаюсь, что операцией поиска будут пользоваться так уж часто, если конечно вы не поисковик разрабатываете

Часто пользуются. Не поисковик, но это главная операция. Кстати, вот статья на тему http://www.xakep.ru/magazine/xa/128/020/1.asp

Я почти на 100% уверен, что вам мускла хватит за глаза. пусть даже на каждый поисковый запрос новая запись в таблице. при нагрузке в 10000 инсертов в день, получаем 300000 в месяц. старые записи (больше месяца) можно удалять или в архивную таблицу переносить, если они нужны конечно.

если вдруг нагрузка вырастет - можно будет и с NoSQL заморочиться. Главное раньше времени лишней работы не делать. Не надо заниматься оптимизацией раньше времени!

Нагрузка будет больше, чем 10000. Это кол-во людей, а один человек может 10 раз поиск использовать. Или больше.