Использование поля "params" в sql-запросе - Joomla 2.5: Общие вопросы

Многие данные в Joomla хранятся в базе данных  JSON-формате
в частности многочисленные параметры
подскажите, пожалуйста, как можно использовать их с sql запросе

никак, только заранее разбирать в PHP и передавать в запрос обычным образом
сравнить строку в json никак не выйдет в мускуле

никак, только заранее разбирать в PHP и передавать в запрос обычным образом
сравнить строку в json никак не выйдет в мускуле

Оказалось очень даже решаемо.


нашел здесь: http://hashcode.ru/questions/28377/%D0%BA%D0%B0%D0%BA-%D1%81%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%B8%D1%82%D1%8C-%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81-%D0%BA-mysql-%D0%B2%D0%BA%D0%BB%D1%8E%D1%87%D0%B0%D1%8E%D1%89%D0%B8%D0%B9-json-%D0%BF%D0%B0%D1%80%D0%B0%D0%BC%D0%B5%D1%82%D1%80

Aeliot понятно, что решаемо, к примеру можно и like использовать зная поле. Вот вопрос быстродействия. Насколько такой запрос выполняется быстро. И beliyadm вам правильно ответил. Вы должны понимать из какого количества данных вы собираетесь выбрать. Порою проще выбрать все строки а потом в php их обрабатывать. Да ив приведенной вам ссылке прямо написано, что это извращение

Fedor Vlasenko,
вы хотите сказать, что циклом foreach в php (а порой несколькими циклами для достижения того же результата) обойти то же количество записей будет быстрее?

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

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

Давайте говорить конкретно. Записей то сколько?
И не забываем что MySQL не  единственный способ хранения данных. Середнячок так сказать? Потому имеет наибольшую популярность, удобен и покрывает на 98% потребностей. Вы бы лучше описали вашу задачу, чего хотите получить и, что имеете в данных

Да регулярно приходится доставать из базы то одни, то другие данные.

На данный момент разбираюсь с временными зонами.
Временная зона пользователя, как это очень часто бывает в Joomla, хранится в json формате в одном поле с другими параметрами.
Задал вопрос по работе с временными зонами здесь: Как в Joomla реализована работа с TimeZone и как это использовать в своем расширении?
Но пока жду ответа пытаюсь решить вопрос в прямую.

В таком случае вам нужно:
1. Написать запрос и обработать данные в php записав в свою таблицу
2. Написать свой плагин  на событие http://docs.joomla.org/Plugin/Events/User#onUserAfterSave где вы будете писать данные временной зоны в свою таблицу, и с ней уже работать

Немного не в тему, но может дадите ссылку на то, как создавать подобные плагины?

Вообще зависит от задачи - вам что, надо массово обрабатывать временные зоны юзеров?
Если надо для отдельного пользователя - почему не вытаскивать его средствами JFactory

А что касается оценки быстродействия - сгенерировать таблицу на 10000 юзеров, написать в двух вариантах и сравнить по времени.

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

Сервисы для быстрого создания модулей, компонентов и плагинов
Єто как создавать заготовки. В нете полно статей, введите событие в Google, сразу найдете интересные статьи

А не проще обьект $user = JUser::getInstance( $id ); использовать? Для текущего юзера вообще запрос не понадобится делать.

А не проще объект $user = JUser::getInstance( $id ); использовать? Для текущего юзера вообще запрос не понадобится делать.

Ну вот самый простой пример, захотел я вывести всех пользователей одной временной зоны? Для одного пользователя уже спрашивали

Записей то сколько?

Записей то сколько?

Нужно обработать порядка 100-200 записей, в которых около десятка долей с датой. т.е. нужно одним махом преобразовать порядка 1000-5000 дат.
И это практически в начале жизни базы. Через полгода - год цифры будут гораздо больше.
Если делать всё это в php, то получится такая куча вызовов, что сервер может не дождаться окончания обработки скрипта и свалится с ошибкой таймаута.

И не забываем что MySQL не  единственный способ хранения данных. Середнячок так сказать? Потому имеет наибольшую популярность, удобен и покрывает на 98% потребностей.

Да и мои потребности ещё как минимум год будет полностью покрывать

Вы бы лучше описали вашу задачу, чего хотите получить и, что имеете в данных

Даже не знаю как описать, чтобы коротко и понятно.
Если по простому, то в таблице ведется учет работы с заказами. Даты должны вводиться "в естественной форме", т.е. если происходит какое-то событие, скажем в 9:35, то пользователь вносит его именно в таком виде. Скрипт при сохранении преобразует его в локальное время сервера. При отображении этого поля происходит обратное преобразование, чтобы пользователь видел именно то, что вносил.
Думал преобразовывать время в GMT, но, как понимаю, тогда получу некорректный результат, если сравнивать эту дату-время с полем, в которое данные были внесены с помощью функции NOW(). Впрочем, если NOW() обернуть в DATE_ADD() или что-то подобное, то можно хранить дату и в GMT.

Но это мелочи. Пару полей можно и в php конвертнуть.
Что делать, когда в "удобочитаемый вид" нужно преобразовать несколько тысяч полей. Т.е. чтобы пользователь мог посмотреть сводную табличку "состояние дел" и чтобы все даты были преобразованы в его локаль.

Создать отдельную таблицу(таблицы), под свои задачи. Не стоит все в таблицу пользователей складывать. Не для этого она предназначена

Чем дальше копаюсь, тем больше понимаю что сам могу реализовать, но, по-хорошему, нужен бы программист.

Fedor Vlasenko, SDKiller
Может кому-то из вас было бы интересно взяться за сопровождение сайта
Вот проект на фрилансере: http://freelance.ru/projects/247941/
Если будет интересно, подробности сброшу в личку.

Нет, я не лесоруб )



Да и аккаунты на всех существующих фрилансах не держу.

упс. исправил. Вечно забываю одну галку снять при создании проекта.

SDKiller, за ответ спасибо. Появится интерес -- пишите.

Aeliot - если вам заранее известна строка - то можно и так, можно и like
Но первое что приходит в голову - работать с массивом json напрямую в MySQL (наиболее оптимальный вариант как кажется) - вот он невозможен
Увы, даже на хабре я понял, что это низзя http://habrahabr.ru/qa/37897/#answer_145755