Покинул форум
Сообщений всего: 808
Дата рег-ции: Янв. 2010 Откуда: Самара
Помог: 17 раз(а)
Есть куча информации(id пользователей) прописанных через запятую в поле в mysql. И я не знаю как лучше проверить есть ли там определенный id или нет.
1 вариант - это выбирать определенную запись вместе с эти полем превращать это в массив с помощью explode и проверять нахождение элемента в массиве с помощью in_array.
2 вариант - это делать с условием LIKE чрез mysql.
Мне нужно выбрать эту запись, и если там есть определенный id то продолжить действия, а если нет то прекращаем работу. Это поле в записи существует только для вот этой проверки, так что если по 2 варианту то его можно и не выбирать... Не знаю что быстрее буде работать(пробовал проверить, вставить в это поле длинный текст, но почему то mysql игнорит этот текст короче надо еще копаться в настройках), также как я знаю массивы хранятся в оперативке на время работы скрипта это еще большой минус. Так как id там быть может очень много...
Посоветуйте как сделать... Заранее благодарен.
Покинул форум
Сообщений всего: 103
Дата рег-ции: Март 2011
Помог: 0 раз(а)
Лучше всего сделать INDEX на это поле и выбирать LIKE'ом. Через explode получится много кода и мало толку.
А вообще, если уместно, то лучше юзать такую систему: создать таблицу соответствий. В ней будут 2 поля: id записи и id соответствия (к примеру). Можно будет просто перебирать эту таблицу
Мелкий
Отправлено: 05 Сентября, 2012 - 13:14:37
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
Лучше выкинуть эту структуру и сделать нормальную.
SkaN пишет:
Лучше всего сделать INDEX на это поле и выбирать LIKE'ом
Like может использовать индекс только для маски 'константа%' (и частный случай - 'константа').
vanicon пишет:
1 вариант - это выбирать определенную запись вместе с эти полем превращать это в массив с помощью explode и проверять нахождение элемента в массиве с помощью in_array.
Вычитываем всю таблицу, гоняем её по сети, оверхед на обработку на стороне PHP
vanicon пишет:
2 вариант - это делать с условием LIKE чрез mysql.
Вычитываем всю таблицу, отсеиваем на уровне mysql.
3 вариант с переделанной структурой и нормальной 3-х табличной связью: вычитываем по мелкому числовому индексу.
----- PostgreSQL DBA
EuGen
Отправлено: 05 Сентября, 2012 - 13:16:01
Профессионал
Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007 Откуда: Berlin
Помог: 707 раз(а)
vanicon пишет:
Есть куча информации(id пользователей) прописанных через запятую в поле в mysql. И я не знаю как лучше проверить есть ли там определенный id или нет.
Самый корректный путь - создать таблицу-связку и определить внешний ключ на соответствующем информациооном поле. Если пытаться в реляционной СУБД нарушать законы реляционных БД, то правильной архитектуры не получится никогда.
После определения вспомогательной таблицы будет достаточно использовать простой JOIN
----- Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
vanicon
Отправлено: 05 Сентября, 2012 - 18:58:02
Частый посетитель
Покинул форум
Сообщений всего: 808
Дата рег-ции: Янв. 2010 Откуда: Самара
Помог: 17 раз(а)
Цитата:
Самый корректный путь - создать таблицу-связку и определить внешний ключ на соответствующем информациооном поле. Если пытаться в реляционной СУБД нарушать законы реляционных БД, то правильной архитектуры не получится никогда.
Я уже думал о такой связке, но почему то не выбрал этот путь, ведь даже если для каждого пользователя создавать свою такую таблицу связку. Примерно около 50-100 тыс строк для одной записи в среднем. Даже если делать на все поля индексы(на id_post и user), то мне почему - то кажется что выборка с помощью этой табличке будет занимать весьма длительное время... Или я в чем - то ошибаюсь?
----- Так было, так есть и так будет
EuGen
Отправлено: 05 Сентября, 2012 - 19:04:39
Профессионал
Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007 Откуда: Berlin
Помог: 707 раз(а)
Ошибаетесь. Таблица-связка будет нужна всего одна. Она будет содержать строки вида (user_id, element_id) - соответствующие пользователь с user_id и связанному элементу element_id
----- Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
vanicon
Отправлено: 05 Сентября, 2012 - 19:12:05
Частый посетитель
Покинул форум
Сообщений всего: 808
Дата рег-ции: Янв. 2010 Откуда: Самара
Помог: 17 раз(а)
EuGen, эти id которые я прописывал через запятую, они были привязаны не к пользователя, а к посту, ну а сам пост естественно к пользователю, но для каждого пользователя у меня отдельная таблица постов. По этому выборка происходит по одному индексу. Поэтому я написал, что если создавать еще таблицу связки для каждого пользователя(чтобы не выбирать по 3 индексам, а по 2).
Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007 Откуда: Berlin
Помог: 707 раз(а)
Ну тогда связка между таблицей постов и этими id. И связка между пользователями и постами (итого 2 таблицы).
----- Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
Мелкий
Отправлено: 05 Сентября, 2012 - 19:23:11
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
vanicon пишет:
(чтобы не выбирать по 3 индексам, а по 2).
И в итоге по индексу выбирать не можете вообще. Ну и что, по вашему, лучше, fullscan или заведомо более компактный и быстрый бинарный поиск по индексу?
vanicon пишет:
для каждого пользователя у меня отдельная таблица постов
Зачем?
PS: я вполне представляю, когда секционирование на уровне приложения может быть реально нужно. Вопрос в том, осознанно ли это сделано или из простого страха перед таблицей в, о ужас!, даже пару десятков тысяч строк?
----- PostgreSQL DBA
vanicon
Отправлено: 05 Сентября, 2012 - 19:27:21
Частый посетитель
Покинул форум
Сообщений всего: 808
Дата рег-ции: Янв. 2010 Откуда: Самара
Помог: 17 раз(а)
Цитата:
Зачем?
Для такого чтобы использовать только 1 тока индекс(id_post), а выбирать все посты пользователя можно и без индекса так как отдельная таблица есть. Разве лучше когда 1 таблица и использовать 2 индекса, с большим объемом информации разве это лучше?
Ps Ну если б я рассчитывал тока на пару десятков тысяч, то я бы так и сделал, но если будет около 1 млн строк и более...
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
vanicon пишет:
но если будет около 1 млн строк и более...
Ладно, недооценил вас.
Можете читать как
Цитата:
или из простого страха перед таблицей в, о ужас!, даже в несколько десятков млн. строк?
Смысл, в сущности, не меняется.
vanicon пишет:
Разве лучше когда 1 таблица и использовать 2 индекса, с большим объемом информации разве это лучше?
В общем случае - да, значительно лучше.
Даже если сейчас нет такой необходимости, то потом понадобится:
- вывести ленту постов (опционально, друзей). Само собой, отсортированную по датам.
- активность пользователей за месяц, неделю
- вся агрегация данных, вся сортировка
Как вы это собираетесь делать?
----- PostgreSQL DBA
vanicon
Отправлено: 05 Сентября, 2012 - 20:21:58
Частый посетитель
Покинул форум
Сообщений всего: 808
Дата рег-ции: Янв. 2010 Откуда: Самара
Помог: 17 раз(а)
Цитата:
В общем случае - да, значительно лучше.
Смотря в каком случае, мне на данный момент волнует производительность того или иного варианта. Если с использованием индексов и отдельной таблицей, разница в производительности ничтожна то почему бы и нет. Ну а если разница все же есть, то тогда выберу в строну производительности.
Цитата:
- вывести ленту постов (опционально, друзей). Само собой, отсортированную по датам.
- активность пользователей за месяц, неделю
- вся агрегация данных, вся сортировка
Ну лично я решаю подобные проблемы с доп.функционалом потом, сначала сделав самое нужное. Ну а уже потом если нужно, то уже можно сделать...
----- Так было, так есть и так будет
Мелкий
Отправлено: 05 Сентября, 2012 - 21:10:50
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
vanicon пишет:
Смотря в каком случае, мне на данный момент волнует производительность того или иного варианта.
Берёте, и измеряете на ожидаемой нагрузке в ожидаемом отношении r/w.
Поддержка и поиск по целочисленному индексу - спички.
А погоня за чистой производительностью - это крест на горизонтальном масштабировании, т.к. оно требует некоторого оверхеда. Это крест и на данных - транзакционная обработка априори более ресурсоёмка, а без транзакций - данные побились, а вы даже не представляете, какие и где.
Идея искать записи Like'ом или вычитывая на приложение всё и там разбирать - какая производительность? Забудьте это слово, его не достичь с такими мыслями в принципе.
vanicon пишет:
Ну а уже потом если нужно, то уже можно сделать...
Ну вот и будет работать очень медленно.
----- PostgreSQL DBA
vanicon
Отправлено: 05 Сентября, 2012 - 21:27:19
Частый посетитель
Покинул форум
Сообщений всего: 808
Дата рег-ции: Янв. 2010 Откуда: Самара
Помог: 17 раз(а)
Мелкий, Возможно я некорректно задал вопрос, попробую задать конкретнее.
Где-то читал тут на форуме мельком что Вы изучали реляционную модель данных - это очень хорошо. 1 вопрос - почти часть второго... Как Вы считаете индивидуальную таблицу постов для каждого пользователя. Для поиска записей не по 1, а без него, простой вывод с таблицы. Как я уже писал записей ожидается много, и конечно меньше их не будет... Или Вы считаете что неважно сколько записей будет в таблице, по 1 индексу будет выбираться быстрее чем без него и по отдельной таблице? Или какие проблемы Вы видите в этой реализации? Также по логике чем больше этих данных в таблице тем и хуже будет выбираться из нее, хоть по индексу хоть как...
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
vanicon пишет:
Где-то читал тут на форуме мельком что Вы изучали реляционную модель данных - это очень хорошо
С точки зрения реляционной логики - вопрос не стоит вовсе. Посты - 1 сущность, значит одна таблица. Всё, других вариантов не существует вообще.
vanicon пишет:
Для поиска записей не по 2, а по 1 индексу.
Ну и что? Какая проблема-то? Все вторичные индексы innoDB ссылаются на первичный ключ, и отлично живут весьма огромные таблицы.
vanicon пишет:
Как я уже писал записей ожидается много
С чего вы взяли, что это - много? Такое хранилище пролопатит даже один-единственный сервер MySQL. (Добавление)
vanicon пишет:
Или какие проблемы Вы видите в этой реализации?
В отсутствии будущего и ужасных костылей тут же, как понадобится любая агрегация. А она понадобится. Иметь проект и даже представления не иметь о происходящих там делах - невозможно.
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.