let cont1 = {
"line1":"Здесь длинный <br> текст",
"line2":"Кликните по <a href='https://google.com'>ссылке</a>"
};
console.log(cont1.line1 + cont1.line2);
//Здесь&nbsp;длинный <br> текстКликните по <a href='https://google.com'>ссылке</a>"а как пользоваться этой функцией?ютуб умеет автоматически генерировать субтитры, остается их оттуда достать, в принципе есть хром плагины которые достают текст субтитров в текстовый файлик.
Люди делают субтитры прямо на видео - это то же самое?Если не ошибаюсь, это фишка кап ката.
Если загружу, могут предъявить авторское право?Хз, зависит от видео, можно попробовать загрузку с доступом только по ссылке, так в теории оно не будет публичным и жаловаться на него будет некому.
Нормализовывать вы пишите смешноЯ не это писал, я писал что стандартный подход в вордпрессе - сделать хреново и страдать. Не столько из какой-то вредности, сколько в угоду универсализации. Где-то это нормально прокатывает, а где-то вылазят вот такие грабли...
но именно это и предлагаете.Опять же - я написал как делать нормально, но в текущем виде нормализовать бд без перестройки структуры данных невозможно. Как минимум надо завести список пользователей с уникальными идентификаторами, логично что использовать имена для идентификации идея не из лучших.
мой вопрос был в другом, если это не вордпресс сделал, значит плагин, но даже так, значит в плагине должны быть инструменты для десериализации и подготовки объекта в адекватном виде. И, тогда этим инструментом и надо воспользоваться.В итоге придет та же проблема, у вас нет уникально идентифицированных данных, так как единственным уникальным идентификатором в рамках логики приложения будет айди записи работника, а в сериализованных данных он отсутствует.
Не говоря уже о том, что "полный прямой перебор всех записей, минуя индексы бд" не всегда худший сценарий, а бывает, что наилучший.Бывает что и палка стреляет. В общем случае это зло, а в тех случаях где перебор работает лучше индексов обычно движок бд сам отдает предпочтение перебору.
Проблема указанных запросов не в этом, а в использовании функций regexp или like, вот они действительно сильно замедлят фильтрацию.Странное утверждение. Оба условия плохо сказываются на производительности, и что будет больше снижать скорость зависит от много чего, например при большом количестве записей и коротких строках бОльшим фактором торможения будет именно отсутствие индекса. Тем более что само по себе налагаемое условие по поиску вайлдкард/регекс в строке автоматически приводит к игнорированию индексов.
WHERE employee.id = 33 и подобными, используя агрегирующие функции, такие как sum(), count() и тд.