Есть куча информации(id пользователей) прописанных через запятую в поле в mysql. И я не знаю как лучше проверить есть ли там определенный id или нет.
1 вариант - это выбирать определенную запись вместе с эти полем превращать это в массив с помощью explode и проверять нахождение элемента в массиве с помощью in_array.
2 вариант - это делать с условием LIKE чрез mysql.
Мне нужно выбрать эту запись, и если там есть определенный id то продолжить действия, а если нет то прекращаем работу. Это поле в записи существует только для вот этой проверки, так что если по 2 варианту то его можно и не выбирать... Не знаю что быстрее буде работать(пробовал проверить, вставить в это поле длинный текст, но почему то mysql игнорит этот текст короче надо еще копаться в настройках), также как я знаю массивы хранятся в оперативке на время работы скрипта это еще большой минус. Так как id там быть может очень много...
Посоветуйте как сделать... Заранее благодарен.

Лучше всего сделать INDEX на это поле и выбирать LIKE'ом. Через explode получится много кода и мало толку.
А вообще, если уместно, то лучше юзать такую систему: создать таблицу соответствий. В ней будут 2 поля: id записи и id соответствия (к примеру). Можно будет просто перебирать эту таблицу

Лучше выкинуть эту структуру и сделать нормальную.


Like может использовать индекс только для маски 'константа%' (и частный случай - 'константа').


Вычитываем всю таблицу, гоняем её по сети, оверхед на обработку на стороне PHP


Вычитываем всю таблицу, отсеиваем на уровне mysql.

3 вариант с переделанной структурой и нормальной 3-х табличной связью: вычитываем по мелкому числовому индексу.

Самый корректный путь - создать таблицу-связку и определить внешний ключ на соответствующем информациооном поле. Если пытаться в реляционной СУБД нарушать законы реляционных БД, то правильной архитектуры не получится никогда.
После определения вспомогательной таблицы будет достаточно использовать простой JOIN

Я уже думал о такой связке, но почему то не выбрал этот путь, ведь даже если для каждого пользователя создавать свою такую таблицу связку. Примерно около 50-100 тыс строк для одной записи в среднем. Даже если делать на все поля индексы(на id_post и user), то мне почему - то кажется что выборка с помощью этой табличке будет занимать весьма длительное время... Или я в чем - то ошибаюсь?

Ошибаетесь. Таблица-связка будет нужна всего одна. Она будет содержать строки вида (user_id, element_id) - соответствующие пользователь с user_id и связанному элементу element_id

EuGen, эти id которые я прописывал через запятую, они были привязаны не к пользователя, а к посту, ну а сам пост естественно к пользователю, но для каждого пользователя у меня отдельная таблица постов. По этому выборка происходит по одному индексу. Поэтому я написал, что если создавать еще таблицу связки для каждого пользователя(чтобы не выбирать по 3 индексам, а по 2).

Ну тогда связка между таблицей постов и этими id. И связка между пользователями и постами (итого 2 таблицы).

И в итоге по индексу выбирать не можете вообще. Ну и что, по вашему, лучше, fullscan или заведомо более компактный и быстрый бинарный поиск по индексу?


Зачем?
PS: я вполне представляю, когда секционирование на уровне приложения может быть реально нужно. Вопрос в том, осознанно ли это сделано или из простого страха перед таблицей в, о ужас!, даже пару десятков тысяч строк?

Для такого чтобы использовать только 1 тока индекс(id_post), а выбирать все посты пользователя можно и без индекса так как отдельная таблица есть. Разве лучше когда 1 таблица и использовать 2 индекса, с большим объемом информации разве это лучше?
Ps Ну если б я рассчитывал тока на пару десятков тысяч, то я бы так и сделал, но если будет около 1 млн строк и более...

Ладно, недооценил вас.
Можете читать как

Смысл, в сущности, не меняется.


В общем случае - да, значительно лучше.
Даже если сейчас нет такой необходимости, то потом понадобится:
- вывести ленту постов (опционально, друзей). Само собой, отсортированную по датам.
- активность пользователей за месяц, неделю
- вся агрегация данных, вся сортировка
Как вы это собираетесь делать?

Смотря в каком случае, мне на данный момент волнует производительность того или иного варианта. Если с использованием индексов и отдельной таблицей, разница в производительности ничтожна то почему бы и нет. Ну а если разница все же есть, то тогда выберу в строну производительности.

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

Берёте, и измеряете на ожидаемой нагрузке в ожидаемом отношении r/w.
Поддержка и поиск по целочисленному индексу - спички.
А погоня за чистой производительностью - это крест на горизонтальном масштабировании, т.к. оно требует некоторого оверхеда. Это крест и на данных - транзакционная обработка априори более ресурсоёмка, а без транзакций - данные побились, а вы даже не представляете, какие и где.
Идея искать записи Like'ом или вычитывая на приложение всё и там разбирать - какая производительность? Забудьте это слово, его не достичь с такими мыслями в принципе.


Ну вот и будет работать очень медленно.

Мелкий, Возможно я некорректно задал вопрос, попробую задать конкретнее.
Где-то читал тут на форуме мельком что Вы изучали реляционную модель данных - это очень хорошо. 1 вопрос - почти часть второго... Как Вы считаете индивидуальную таблицу постов для каждого пользователя. Для поиска записей не по 1, а без него, простой вывод с таблицы. Как я уже писал записей ожидается много, и конечно меньше их не будет... Или Вы считаете что неважно сколько записей будет в таблице, по 1 индексу будет выбираться быстрее чем без него и по отдельной таблице? Или какие проблемы Вы видите в этой реализации? Также по логике чем больше этих данных в таблице тем и хуже будет выбираться из нее, хоть по индексу хоть как...

С точки зрения реляционной логики - вопрос не стоит вовсе. Посты - 1 сущность, значит одна таблица. Всё, других вариантов не существует вообще.


Ну и что? Какая проблема-то? Все вторичные индексы innoDB ссылаются на первичный ключ, и отлично живут весьма огромные таблицы.


С чего вы взяли, что это - много? Такое хранилище пролопатит даже один-единственный сервер MySQL.
(Добавление)

В отсутствии будущего и ужасных костылей тут же, как понадобится любая агрегация. А она понадобится. Иметь проект и даже представления не иметь о происходящих там делах - невозможно.