Нормализовывать вы пишите смешноЯ не это писал, я писал что стандартный подход в вордпрессе - сделать хреново и страдать. Не столько из какой-то вредности, сколько в угоду универсализации. Где-то это нормально прокатывает, а где-то вылазят вот такие грабли...
но именно это и предлагаете.Опять же - я написал как делать нормально, но в текущем виде нормализовать бд без перестройки структуры данных невозможно. Как минимум надо завести список пользователей с уникальными идентификаторами, логично что использовать имена для идентификации идея не из лучших.
мой вопрос был в другом, если это не вордпресс сделал, значит плагин, но даже так, значит в плагине должны быть инструменты для десериализации и подготовки объекта в адекватном виде. И, тогда этим инструментом и надо воспользоваться.В итоге придет та же проблема, у вас нет уникально идентифицированных данных, так как единственным уникальным идентификатором в рамках логики приложения будет айди записи работника, а в сериализованных данных он отсутствует.
Не говоря уже о том, что "полный прямой перебор всех записей, минуя индексы бд" не всегда худший сценарий, а бывает, что наилучший.Бывает что и палка стреляет. В общем случае это зло, а в тех случаях где перебор работает лучше индексов обычно движок бд сам отдает предпочтение перебору.
Проблема указанных запросов не в этом, а в использовании функций regexp или like, вот они действительно сильно замедлят фильтрацию.Странное утверждение. Оба условия плохо сказываются на производительности, и что будет больше снижать скорость зависит от много чего, например при большом количестве записей и коротких строках бОльшим фактором торможения будет именно отсутствие индекса. Тем более что само по себе налагаемое условие по поиску вайлдкард/регекс в строке автоматически приводит к игнорированию индексов.
WHERE employee.id = 33 и подобными, используя агрегирующие функции, такие как sum(), count() и тд.
ну как же не показывает? Вон у него в вопросе результат запроса видно. И в нём php-сериализация.Да на факт, это же вордпресс, там вполне может оказаться какая-то прослойка, которая сгоняет промежуточные данные в сериализацию и засовывает в stdClass Object. Не удивлюсь. Хотя логика подсказывает что тупо скроежопили на нормальной структуре и запихали все в одно поле...
сериализованный объект, то на стороне MySQL не так уж и сложно конвертировать его в честный JSONТут согласен, проще создать доп. поле и прогнать 1 раз через пхп все строки и тогда уже записать жсон в новое поле. Только в любом случае еще нужно логику сохранения сущности поменять...
Uncaught ReferenceError: $ is not definedне подключен jquery.
Нет, нет, имеется ввиду как сделать чтобы при выборе города селектом, url менялся.Яваскриптом, как еще. Ончейнж виндоу.локэйшн.хреф = новый урл.
Если не ошибаюсь, это фишка кап ката.
Хз, зависит от видео, можно попробовать загрузку с доступом только по ссылке, так в теории оно не будет публичным и жаловаться на него будет некому.