Как вывести нужную строку (оператор LIKE)?

Question

[Евгений Иванов]

Таблица содержит 2 столбца.
Первый столбец - идентификаторы пользователей. Формируются php implode (нет запятой в конце строки, но если нужно можно и поставить).
Второй столбец - информация.

Нужно чтобы каждому пользователю выводилась та строка, где есть его id.
Например 28 - Информация 2 и Информация 3.

Мой SQL запрос работает некорректно

SELECT * FROM `table` WHERE `users_id` LIKE '%28%'; // или %28 или 28%

Я никак не могу выбрать именно совпадение 28.
Ведь есть 228. Изменяем запрос - ставим % спереди выводит 288

Как вывести нужную строку (оператор LIKE)?

Comments

[Akina]

Нормализовать.

Очень временно - использовать FIND_IN_SET(). Но будет тормозить.

[Евгений Иванов]

Akina, так нормализовано же.
В первой таблице хранятся пользователи id login pass
Во второй информация.
Пользователю нужно показать инфу. для этого его идентификатор помещается в поле второй таблицы.
По другому никак.

Если бы одному пользователю нужно было бы показать информацию - то джоин.
Но тут информация предназначена нескольким пользователям.

[Akina]

Евгений Иванов, Вы неправильно понимаете, что такое нормализованные данные. CSV , а также JSON, XML и так далее- это ДЕНОРМАЛИЗАЦИЯ. Всё.

Если бы одному пользователю нужно было бы показать информацию - то джоин.
Но тут информация предназначена нескольким пользователям.

Это результат неверного понимания и, как следствие, некорректно проделанного анализа. Следствием которого и явилась денормализованная структура.

Answer 1

[Immortal_pony]

SELECT * FROM `table` WHERE FIND_IN_SET('28', `users_id`) > 0

Если уж очень сильно хочется именно LIKE, то

SELECT * FROM `table` WHERE (`users_id` LIKE '28,%' OR `users_id` LIKE '%,28,%' OR `users_id` LIKE '%,28')

Comments

[Евгений Иванов]

Спасибо, потестирую.

Этот запрос понятен.

SELECT * FROM `table` WHERE (`users_id` LIKE '28,%' OR `users_id` LIKE '%,28,%' OR `users_id` LIKE '%,28')

А вот тут не очень понятна логика

SELECT * FROM `table` WHERE FIND_IN_SET('28', `users_id`) > 0

FIND_IN_SET должна вернуть позицию строки с содержимым 28 между запятыми.
Но это работает (что хорошо) и без запятых.
Работает и с 28 и с 28, и с ,28,
Не работает c 282 и 1, 282 и 228,1
То есть прямо то что мне надо. Функция понимает, что мне надо именно 28, а не 228 и т.д.

[Immortal_pony]

Евгений Иванов А что именно непонятно-то?)

[Евгений Иванов]

А что именно непонятно-то?)

Магия какая то - работает не по мануалу. FIND_IN_SET должна искать между запятыми, а находит и без них.

Answer 2

[FanatPHP]

Спустить это дерьмо в унитаз и сделать БД в нормальной форме.
Идентификаторы пользователей лежат в отдельной таблице.
После этого достаются тупым джойном без всяких лайков

должна быть ещё одна таблица, в которой два поля, information_id и user_id
и три записи
2|29
2|28
2|31
и тупой запрос,
SELECT i.* FROM information i, users_info ui WHERE i.id=ui.information_id and ui.user_id=28;

Comments

[Евгений Иванов]

Бд в нормальной форме.
Идентификаторы лежат в отдельной таблице. id userlogin pass
А есть таблица user_ids information
Если в поле user_ids есть идентификатор из первой таблицы - показываем запись.

Вы не сможете объединить таблицы join.
Одному пользователю могут быть доступны 2 и более строк из таблицы с инфой.
Пользователи создаются и удаляются.
Вы не можете создать для каждого пользователя отдельное поле во второй таблице.

[FanatPHP]

Я всё могу. Я букварь читал. В котором написано, что такое нормальная форма.
Обновил ответ

[galaxy]

Евгений Иванов, ваша таблица user_ids information даже не в первой НФ

Делайте, как сказали. На худой конец с костылем, как писал Akina

[FanatPHP]

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

[Евгений Иванов]

FanatPHP, да, это хорошее решение.
Но мне надо менять много логики в моем приложении.
По моему было логично хранить идентификаторы доступа в строке с разделителями.
В PHP нет проблем найти строку в подстроке. Аналогично и в MySQL если бы идентификатор был один.
SELECT * FROM `table` WHERE id='$id'
Неужели SQL не может найти подстроку в строке. Регулярками, например...

[FanatPHP]

Это не "хорошее" решение. Это решение, буквально, уровня "2х2=4". Хорошее? Ну наверное, если вы предполагаете какие-то другие варианты.
Новичкам очень многие вежи кажутся логичными. Например писать WHERE id='$id' вместо WHERE id=?
А потом писать слезные посты на Тостер "ой миня паламали, как мине защитица, причем за 6 секунд и две копейки!!!!!!11111"
SQL всё может. Но сначала надо прочитать букварь. Чтобы идиотские решения не казались логичными.
И срочно переделывать эту офигенно логичную логику в своём приложении
потому что переделывать все равно придется, но потом будет гораздо больнее.

[galaxy]

FanatPHP, я не пытаюсь. По моему ощущению, ваш подход не работает.
Например, человек не понимает основ SQL (где кавычки надо, а где нет, например, или чем insert от update отличается), а вы ему выкатываете свою простыню (очень правильную, конечно), как использовать PDO с подготовленными запросами и пр. Да ему костыль нужен, чтобы лабу спихнуть или закрыть ошибку здесь и сейчас, а ему предлагается весь код выбросить на помойку. Никто не будет этого делать.
Конечно, надо правильно писать. Но всему свое время. Имхо.

[FanatPHP]

galaxy, каких основ он не понимает? 3 года на тостере, 300 вопросов. Сколько еще лет надо в ясельках пробыть, чтобы начать делать по-человечески? 5? 10?

[galaxy]

FanatPHP, ок, в его случае я не настаиваю)))

[Евгений Иванов]

galaxy, FanatPHP,

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

Придется. И это нормально. Вы не видите всего pi...всю систему.
Сначала делаем как можем, быстро, без подготовленных запросов, фильтрации данных и т.д. Никто не будет ломать. Нужен прототип.
А по ходу юзания собираем фидбек и делаем вторую, третью, сотую версию - исправляя ошибки.
А там ошибок будет и хотелок... Или не будет.

Ваш запрос правильный. И логичный. Но в силу определенных причин (конкретно трудности планирования) получается вот это. Должен был быть 1 пользователь и простейший запрос а тут раз...
И вот выбор - или финт ушами или рефракторинг и переделывание кучи логики. А это время.
А система прототип и не факт что взлетит.
Поэтому пока вот так.

В общем написал такое. Вроде работает.

SELECT * FROM `table` WHERE `users_id` RLIKE "[[:<:]]'.$userId.'[[:>:]]

galaxy

чем insert от update отличается

вставляет, обновляет? )

как использовать PDO с подготовленными запросами

Накрутив это на шаблонизатор и ООП (про ООП в PHP после C# говорить не охота, перегрузку методов завезут? банальное..)... Так можно 2 месяца просидеть.
Я пока даже банально фильтрацию данных не делаю. Время.
Нужен прототип. И требования изменяются. Поэтому финты ушами.

Нет я не профи, ни разу. Просто как говорится по ходу пьесы возникают непредвиденные обстоятельства.
А на качественное планирование времени нет.

[FanatPHP]

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

[Евгений Иванов]

FanatPHP,

а на деле

на деле вам скажут 1 пользователь 1 строка с инфой.
Какой запрос вы напишите?
А потом скажут а давайте много пользователей и 1 строка с инфой.
А там уже куча логики завязана.
Будете переписывать?
А завтра будут новые хотелки...т.е. бизнес требования.
Вот отсюда и идут финты ушами. А не от нежелания делать всё как надо с первого раза.
Буду переписывать как надо? Скорее всего да. Но попутно учту и другие требования, чтобы не переписывать в третий раз.
А пока нужно написать запрос, который работает и по возможности не сильно нагружает бд.

[FanatPHP]

не надо вот этого лепета
хранение данных в БД никак не отражается на коде. запрос меняется - ну так он в любом случае меняется

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

[Евгений Иванов]

FanatPHP

это было видно на примере шаблонизатора

Нормально вроде сделал. В меру своих сил.

static function GetTemplateCode($templateFileName, $templateArgumentsArray) {
$templateFullPath=$_SERVER['DOCUMENT_ROOT'].'/templates/'.$templateFileName;
ob_start();
include $templateFullPath;
return ob_get_clean();
}

прикрыть желание сделать по-своему

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

Книжки надо читать. Пишут им книжки каждый год, а они не читают. А им всё пишут.
Этот автор напишет, другой. Уже куча книг по одной теме - а нет, всё задают вопросы в интернете.
Ленивые...

Никто не любит "плавать в нечистотах", особенно умные люди.
Но IT быстро развивается и единого подхода (делать как нормальные люди) тут нет. Иначе откуда было бы столько легаси кода? Образования нормального нет - Гоша дударь про PHP такого расскажет.
Можно посмотреть курсы PHP Специалист Баумана - лучше, но...ООП в PHP, пространство имен PRS стандарт...по сравнению с C# и его идеологией (Шевчук - эксперт Майкрософт хорошо объясняет суть и идею ООП) мягко говоря не очень.

Я не вижу единого подхода к разработке. Все пишут как могут.
Я пишу так. И вообще есть планы перейти с PHPшного ООП назад на функциональное в силу отсутствия нормальной поддержки ООП, в силу того, что экземпляр класса хранится в памяти только от начала до окончания выполнения скрипта. Это не десктоп - процесс висящий в памяти, это выполнилось и все.
И unset часто не надо - всё скрипт завершен. Другой подход.
И как следствие куча статики и написания ООП в процедурном стиле. Такое ООП нам не нужно )

хранение данных в БД никак не отражается на коде

Код работает с БД. Они связаны. В идеале не должно отражаться - нет никакой разницы чем и как обрабатывать БД. На практике есть - писать одну строчку кода или 10.
Либо пишем код под БД, либо БД проектируем под код.