- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева

В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть таблица с несколькими столбцами однотипных данных: stolb_p, stolb_m, stolb_r, stolb_k и т.д.
Также на входе есть переменная с определенным словом. Нужно проверить все строки и столбцы на соответствие этому слову и если это слово присутствует в ячейке, также нужно выяснить в каком именно столбце.
Я в MySQL не профи, могу реализовать только с помощью нескольких простых запросов, но это приведет к нагрузке на сервер БД.
Можно ли осуществить задуманное одни-двумя запросами? Если да, то как?
Буду благодарен за любые советы. :)
В information_schema.COLUMNS содержится информация о названиях столбцов.
Обычно на оборот разбивают сложные запросы на несколько простых, как вы узнали что это приводит к нагрузки на сервер?
Allality Почитай про объединения в mysql - LEFT JOIN например.
minor Зачем делать лишние запросы в скриптах когда можно сделать одним? MYSQL заточен чтобы обрабатывать сложные запросы, пускай он и занимается этим, а не делать множество ненужных мелких запросов из скрипта.
Зависит от ситуации, один большой запрос трудно читать разработчикам, куча джойнов медленнее работает чем отдельные запросы опять же от ситуации не всегда.
Посмотрел про JOIN, вроде как он для нескольких таблиц используется. У меня одна таблица, с несколькими столбцами...
Аццкий запрос:
Уже ближе к телу. А как сказать PHP в каком столбце находится найденная строка?
Это отвратительное решение с точки зрения производительности. Лучше использовать пара отдельных запросов, тем более находя вхождение не будут выполнятся лишние запросы. И не забываем что like очень медленно работает.
Это отвратительное решение с точки зрения производительности. Лучше использовать пара отдельных запросов, тем более находя вхождение не будут выполнятся лишние запросы. И не забываем что like очень медленно работает.
Вы говорите про решение, которое было выше или про то, которое у вас в цитате? Есть ли способ сделать это без лишней нагрузки на сервер? Дело в том, что этот код будет исполняться при загрузке каждой страницы, а хостинг - обычный shared...
Я предложил как определить поле для примера выше. Но сам по себе путь не правильный.
А как сделать правильно зависит от того что вы хотите.
Если вам нужен поиск, который инициирует пользователь, то в таком случае нагрузка на сервер будет в целом небольшая, можно использовать решение с одним сложным запросом или разбить запрос на несколько мелких. Так же, чтоб обезопасить себя от ДДОСа надо на поиск установить капчу и прикрутить механизм ограничения запросов при определенной нагрузке.
Если же инициировать запрос будет ваш скрипт при загрузке определенных страниц сайта, то в таком случае проблем с производительностью не избежать. Лучше или отказаться от задуманного, либо получше продумать и перестроить структуру БД, либо создать специальные служебные таблицы с индексами и искать в них по средством '=', а не 'like'.