- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Задался определенным вопросом, может есть решения лучше, по сему с вопросами на СЕ, к спецам.
В общем есть пользователь, для него есть определенные данные штук 30, которые он может включить и выключить. Эти данные находятся в специальной таблице.
Так вот, что бы выводить ему эти данные с его предпочтениями , я использую , что-то типа такого
id IN (1,2,3,4,5,6,30);
данные 1,2,3,4,5,6,30 я храню в таблице привязанной к пользователю в виде ,1,2,3,4,5,6,30, (для удобного поика, удаления или замены элемента, например проверка на наличие 1 поля проходит по такой маске ,1,).
С одной стороны
- храним данные готовые сразу использоваться в WHERE id IN (..
- так же быстрое и простое редактирование полей
- намного проще чем хранить например массив, и проще работать чем с массивом
- кол-во данных не большое
с другой стороны
- возможно есть более интересные, быстрые, и простые в вычислениях методы?
Буду признателен за направление мыслей в нужную сторону.
Если речь именно о битах/флагах, то можно использовать битовые операторы.
"Можно" — не значит "нужно".
Чтобы понять, будет ли какой-то прирост в производительности или уменьшение объёма хранимой информации, нужно рассматривать конкретную ситуацию более углублённо.
Спасибо за ответ. С битами раньше дела не имел на уровне MYSQL, но понятия кое какие имею. По сему, вроде бы и хорошо иметь поле из 30 ноликов и единиц, нежели, поле вида [ 1, 11, 22, 34, 35,], но не уверен что операции с битами быстрее да и прирост в экономии базы рассматривая разницу этих двух полей думаю не будет больше чем в 2 раза.
Может есть другие варианты? Или мой велосипед вполне жизнеспособный?
Никакого не будет у вас прироста, ни в 2 ни в 1,5 ни в 0,5 раза. И экономии тоже.
Не забивайте голову просто.
задумаля потому что начал смущать вот такой список [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ... 27, 28,] в одном из полез бд. Подумал может я не догоняю и есть для таких нужд что-то проще.
В общем понял. всем спасибо.
Экономия и прирост могут быть в теории.
Если у каждой записи есть куча флагов, например, 64 штуки :), и этих записей мильён, то целесообразнее хранить эти флаги в одном поле BIGINT UNSIGNED, чем в строках. Это сократит и размер таблицы, и индекса, что немаловажно.
Вобщем, положительный эффект может быть заметен, но в каждой ситуации нужно принимать отдельное решение :)
а если добавить связную таблицу типа
ИД флага
значение флага
не заменить, а именно добавить для оптимизации некоторых операций)
(для удобного поика, удаления или замены элемента, например проверка на наличие 1 поля проходит по такой маске ,1,).
при поиске по флагу наверно побыстрее будет отдельная таблица с индексами?
А сколько этих флагов всего? может проще енум со значениями:
"00001"
"00010"
"00100"
и так далее все варианты
что хорошо так это то что это поле не индекс, да и с числами в 64 бита сложнее работать ) чем со строкой.
ну и , есть условия, при которых, строковое поле может быть заполнено значительно меньше 64 бит, а вот битовое поле, уже однозначно будет хранить в каждой записи 64 бита.
---------- Добавлено 21.03.2015 в 12:43 ----------
А сколько этих флагов всего? может проще енум со значениями:
))) может и проще,
сейчас записей 26 )), но вариантов значительно больше чем 26 ))))) , где-то 67108864 = 2*26степени
---------- Добавлено 21.03.2015 в 12:44 ----------
при поиске по флагу наверно побыстрее будет отдельная таблица с индексами?
я думал об этом, но какой от этого практический смысл?
ссылаться в другую таблицу в которой 67108864 записей, что бы получить тоже самое число что в битовых операциях напрямую из числа! лишняя итерация.