Автор |
Сообщение |
Richard Ferlow Гуру Предупреждений : 2
|
|
Вот думаю над такой задачей.
Есть таблица.
И есть массив с id строк нужных из этой таблицы.
Как правильно сделать выборку строк с id из этой таблицы ?
Интересует пример кода запроса.
Мне в голове рисуется нечто с OR ... OR - но почему-то думаю, что это не совсем нужный вариант.
Количество id может быть большим, т.е. не фиксированное кол-во. |
|
|
|
|
DenisP Форумчанин |
|
А эти id у тебя в другой таблице?
Если это просто массив какой-то, то можно еще в строну IN( ) копнуть, или UNION. |
|
|
|
|
BS Эксперт |
|
Если они идут подрят то в вайле напиши id>N and id < M |
|
|
|
|
Richard Ferlow Гуру Предупреждений : 2
|
|
Верно, в другой. Но там они в текстовом поле через запятую перечислены. Поэтому думаю без перегонки в массив не обойтись. |
|
|
|
|
Richard Ferlow Гуру Предупреждений : 2
|
|
BS
Нет, это слишком просто бы было.
Там в том и смысл, что конкретные.
У меня просто знаний MySQL не хватает достаточно
Два тупых способа я конечно придумал, но мне они не катят |
|
|
|
|
Richard Ferlow Гуру Предупреждений : 2
|
|
DenisP
Цитата: |
Если это просто массив какой-то, то можно еще в строну IN( ) копнуть, или UNION. |
Вот тут можно поподробнее ? |
|
|
|
|
BS Эксперт |
|
|
|
|
BS Эксперт |
|
Richard Ferlow писал(а): |
Вот тут можно поподробнее ? |
Получиться примерно что то похожее.
Вопрос теперь с производительностью.
Зависит, что ты хочешь получить.
Может у тя не правильня архитекрута БД? |
|
|
|
|
Richard Ferlow Гуру Предупреждений : 2
|
|
BS
Я понял о чем ты, но такая выборка не подойдет
Думаю может есть какая-то выборка в духе WHERE ID=/тут массив или через запятую как-то/
Потому что если запрос динамически формировать, этих OR будет штук 50 там - думаю это не есть верно. |
|
|
|
|
BS Эксперт |
|
В таком случае храни айдишники отдельно, а не в строке |
|
|
|
|
DenisP Форумчанин |
|
Richard Ferlow
В общем-то это не есть гуд с точки зрения нормализации данных, подумай над схемой данных, может быть все-таки разнесешь по разным полям. И удобнее будет, и производительность повысишь (скорее всего, если объемы будут большие).
Если производительность не особо важна, то условие можно написать вот так (не знаю синтаксиса MySQL, сама идея):
pos( ','||str(ID)||',' , ','||строка_с_ID||',') <> 0
где: pos функция, которая тебе вернет позицию вхождения одной строки в другую; str функция преобразующая число в текст, ','|| и ||',' с двух сторон обрамляют, чтоб крайние значения найти. Предполагаю, что в строке строка_с_ID нет пробелов.
Вот это я извратился |
|
|
|
|
DenisP Форумчанин |
|
Richard Ferlow писал(а): |
DenisP
Цитата: |
Если это просто массив какой-то, то можно еще в строну IN( ) копнуть, или UNION. |
Вот тут можно поподробнее ? |
Это я прдположил до того, как узнал, что у тебя ID в строку засунуты |
|
|
|
|
BS Эксперт |
|
DenisP писал(а): |
Вот это я извратился |
Не то слово, имхо проблема в корне) А мы боримся с её сделствием.
Покешь ка архитикруту БД |
|
|
|
|
Richard Ferlow Гуру Предупреждений : 2
|
|
Просто то, как есть, проектировалось изначально без этого нововведения и было удобным.
В массиве таким образом хранится id элементов, к которым пользователь имеет доступ.
Там где это использовалось - очень удобно.
Еще мысль появилась - права этих нововведений иначе организовать в таблицах, отдельно от того, что есть. Надо подумать.
DenisP
Если по честной, не очень понял что ты имел ввиду Догадываюсь так, что предложил функцию перевода строки в что-то другое |
|
|
|
|
BS Эксперт |
|
Проще распарсить строку....
Повторяю еще раз и медленно строку с айдишниками убираешь, делаешь таблицу, с указателем на поле где раньше была строка и айдишниками. Делаешь внешний ключ, каскадное удаление или что тебе там надо... |
|
|
|
|
DenisP Форумчанин |
|
Richard Ferlow писал(а): |
В массиве таким образом хранится id элементов, к которым пользователь имеет доступ.
|
для этого вводится еще одна таблица, типпичный пример связи многие-ко-многим.
Цитата: |
DenisP
Если по честной, не очень понял что ты имел ввиду Догадываюсь так, что предложил функцию перевода строки в что-то другое |
Нет, предложил ID текущей записи найти в строке, которая содержит список ID.
Т.к. они у тебя разделены запятыми - обрамляем искомый ID запятыми.
Пример: ID =4, Строка_с_ID = 3,4,5,44
Значит ищем ,4, в ,3,4,5,44,
Но ищем меееееееедлеееееенннноооооо |
|
|
|
|
BS Эксперт |
|
DenisP писал(а): |
для этого вводится еще одна таблица, типпичный пример связи многие-ко-многим. |
|
|
|
|
|
Richard Ferlow Гуру Предупреждений : 2
|
|
Хм....
Видимо в этом случае придется вторую схему прав заводить.
Таким образом
Будет две таблицы.
Первая - id user, id строки
Потом делать общий запрос для двух таблиц - из второй выбрать id, где у id user есть id=id строки
Как-то так что ли.
Очень не хочется, потому как чтобы нарастить существующую систему с текстовым полем, нужно просто нарастить то, что есть.
Может тупое сделать преобразование - и строку виду 2,5,7 заменой перевести в id=2 OR id=5 OR id = 7 и использовать в запросе ? ) Сколько интересно запрос выдержит. |
|
|
|
|
BS Эксперт |
|
НИЧЕГО ДЕЛАТЬ НЕ НАДО!!!!!!!!!!!!!
user.id = str.usre_id
Вот условие конкретенации.
user_id в str бует иметь вторичный ключ. Я НЕ ПОНИМАЮ, о каких правах ты говоришь. |
|
|
|
|
DenisP Форумчанин |
|
Ну вот что-то в этом роде
Цитата: |
Может тупое сделать преобразование - и строку виду 2,5,7 заменой перевести в id=2 OR id=5 OR id = 7 и использовать в запросе ? ) Сколько интересно запрос выдержит. |
Проверь сам, наколбась OR-ов штук с тысячу, должно быть какое-то ограничение. Можешь и так сделать, никто не говорит, что это работать не будет. Это не самое красивое решение, но если оно тебя устраивает - значит все Ок. "Есть много способов ободрать кошку"(с) непомнюкто. Но ты все равно должен понимать, что если объемы будут расти, то это место у тебя будет узким по производительности. |
|
|
|
|
|