не понятно стремление хранить именно как битовую маску

так я и не стремлюсь

я спрашиваю чё лучше

создать по отдельной колонке или хранить битовую маску

А база то какая?

мускуль

Ой, все.

ой, всё

Там способов кроме как создавать колонки не существует

Я не уверен что ты не выстрелишь себе в ногу если будешь использовать битмаску.

ну есть ещё вариант с SET и JSON

На btree селективность битмаски будет плохая, а у постгреса есть оптимизации свои для ьитовых операций

А что, в MySQL уже можно делать индексы по JSON?

Только вот про вот эти виртуальные поля, и экстрактирования полей из JSON не надо сейчас.

ой всё

либо денормализация, либо битовая маска, либо eav, либо json вот тебе 4 стула

eav так вообще бутылка.

ну каждый сам выбирает на что садиться

либо денормализация, либо битовая маска, либо eav, либо json вот тебе 4 стула

Да нормально все с битовыми масками. Просто разбирать маску нужно на стороне приложения. А хранить просто как число. И будет счастье

Так и не говорил что плохо)

Да нормально все с битовыми масками. Просто разбирать маску нужно на стороне приложения. А хранить просто как число. И будет счастье

И как же искать в базе по маске? Захерачивать в базу 255 возможных значений? (или сколько там увас бит, или валидных комбинаций)?

И как же искать в базе по маске? Захерачивать в базу 255 возможных значений? (или сколько там увас бит, или валидных комбинаций)?

Собираешь маску которую ищешь. Получаешь число. Ищешь число.

Что не устраивает?

Мой бит может быть установлен в составе другого или ещё шести в комбинации которой я ваще ниипу

Так как мне число то собрать я не понял

Что не устраивает?

Вы точно представляете себе как работает BIT_AND функции в базе данных?

Вы точно представляете себе как работает BIT_AND функции в базе данных?

А вы точно понимаете что такое битовые маски?

Мой бит может быть установлен в составе другого или ещё шести в комбинации которой я ваще ниипу

Это тоже можно посчитать

Добрый всем день, не хотелось бы изобреть велосипед со скриптами, написал чисто для отдела маленькую БД с лицензиями ПО, в связи с тем, что сотрудники часто меняются или переезжают между залами, есть ли в mysql возможность, чтобы рандом просили проверить актуальность записи в таблице рандомных строк, какими то средствами которые есть в mysql выходил запрос на актуализацию данных в таблице? Я не разработчик БД, если вопрос глупый прошу подсказать какими средствами можно это реализовать, объяснять полностью не нужно. Спасибо заранее всем.

Встроенный планировщик и скрипт который будет проверять expire

Встроенный планировщик и скрипт который будет проверять expire

спасибо, буду копать.

Это тоже можно посчитать

Каждая из сущностей хранит int, которое на самом деле битмаска: 10010000 = 144 10011001 = 153 01011001 = 89 Теперь мне надо найти все записи, у которых подняты биты под номерами 8, 5 и 4 и не содержит бита под номером 1. Интересно мне узнать, какое (какие)же числа вы поставите в WHERE часть...

Каждая из сущностей хранит int, которое на самом деле битмаска: 10010000 = 144 10011001 = 153 01011001 = 89 Теперь мне надо найти все записи, у которых подняты биты под номерами 8, 5 и 4 и не содержит бита под номером 1. Интересно мне узнать, какое (какие)же числа вы поставите в WHERE часть...

Ыыыы. Подумай. Это очень просто

Ыыыы. Подумай. Это очень просто

Ыыыы так покажи раз просто.

Ыыыы так покажи раз просто.

https://ru.m.wikipedia.org/wiki/Булева_алгебра

Типичный пример под номером 1.

Вопрос то читали? Что будет в WHERE части.

Вопрос то читали? Что будет в WHERE части.

select * from test where value & conv('10', 2,10);

Ыыыы так покажи раз просто.

Where X&153=152 если mssql или bitand(X,153)=152 если оракл например. Если биты 8,5,4 нужны и 1 не нужен.

С функциями побитовых операций все понятно. Выше предлагали ставить челочисленное число и считать маску в приложении

А, так это не исходная задача)

Собираешь маску которую ищешь. Получаешь число. Ищешь число.

Для меня это выглядит как WHERE mask = 152

Или я читать разучился?

С функциями побитовых операций все понятно. Выше предлагали ставить челочисленное число и считать маску в приложении

Точно так же. Каждый включеный бит это конкретное число в любой другой системе исчисления. То есть поиск каждогл включеного бита есть выборка числа в определенном пределе

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

Об этом речь же?

нет

WHERE mask & n = n или WHERE mask & n > 0

Первое скорее = mask

бля, маски нинужны на самом деле

SET хранится как маска

но опять же вопрос будет ли работать индекс в этом случае? SELECT * FROM tbl_name WHERE FIND_IN_SET('value',set_col)>0;

если я всё правильно понимаю - нет

Индекс не будет работать никогда если на индексированную колонку применяются функции или любые преобразования

Я помню лет 7 назад была у меня похожая идея, с масками, при установлении соответствия произвольному шаблону с атрибутами и свойствами, но в итоге положил на это болт, стал в бд хранить все компактнее, а вычисления делал на клиенте. По сравнению с скл-запросами (включая использование команд реляционной алгебры) производительность выросла порядка на 2 на больших объемах. На мелких тоже почти не просела. Что же касается битовых масок, смотрите не нарвитесь на то, что свойств будет так много, что маска выйдет за границы максимального целочисленного типа в вашей бд.

https://dev.mysql.com/doc/refman/8.0/en/numeric-type-overview.html

BOOL, BOOLEAN These types are synonyms for TINYINT(1). A value of zero is considered false. 

Это ты к чему?

К 100500 столбикам :)

Я помню лет 7 назад была у меня похожая идея, с масками, при установлении соответствия произвольному шаблону с атрибутами и свойствами, но в итоге положил на это болт, стал в бд хранить все компактнее, а вычисления делал на клиенте. По сравнению с скл-запросами (включая использование команд реляционной алгебры) производительность выросла порядка на 2 на больших объемах. На мелких тоже почти не просела. Что же касается битовых масок, смотрите не нарвитесь на то, что свойств будет так много, что маска выйдет за границы максимального целочисленного типа в вашей бд.

64 свойства сложно преодолеть

Я помню лет 7 назад была у меня похожая идея, с масками, при установлении соответствия произвольному шаблону с атрибутами и свойствами, но в итоге положил на это болт, стал в бд хранить все компактнее, а вычисления делал на клиенте. По сравнению с скл-запросами (включая использование команд реляционной алгебры) производительность выросла порядка на 2 на больших объемах. На мелких тоже почти не просела. Что же касается битовых масок, смотрите не нарвитесь на то, что свойств будет так много, что маска выйдет за границы максимального целочисленного типа в вашей бд.

Ты слищком старый. Кодишь в аппе. Молодежи нада что бы все в одном запросе было. Ибо кодписать это думать нужно. А так хоба и сервер кипит

64 свойства сложно преодолеть

У меня есть подозрение что сама задача сформулирована не правильно.

Тут получается потолок - 64 свойства. У меня в том примере было больше.

Точно так же. Каждый включеный бит это конкретное число в любой другой системе исчисления. То есть поиск каждогл включеного бита есть выборка числа в определенном пределе

Еще раз повторю свой вопрос, раз так сложно. Ссылаясь на вашу же фразу — как за одно интовое сравнение сделать AND и OR поиск по маске посчитанной на клиенте?

(никак)

Еще раз повторю свой вопрос, раз так сложно. Ссылаясь на вашу же фразу — как за одно интовое сравнение сделать AND и OR поиск по маске посчитанной на клиенте?

А вас кто то ограничивает одним сравнением?

О, становится интереснее. И сколько же таких сравнений мне придется в базу отправить?

Ты слищком старый. Кодишь в аппе. Молодежи нада что бы все в одном запросе было. Ибо кодписать это думать нужно. А так хоба и сервер кипит

Обычная тема - заказчик жмется на серверное железо, а производительность вынь да положь) При таком подходе хочешь не хочешь а СУБД разгружать приходится.

Давайте ка разберемся.

О, становится интереснее. И сколько же таких сравнений мне придется в базу отправить?

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

А вас кто то ограничивает одним сравнением?

Ваше число — посчитанная маска, она уже жестко задает выключенные биты. Значит мне придется собрать все кобинации всего чего можно игнорировать и что нельзя и придется перечислять с индивирульаной OR маской

И об этом я сказал в самом начале. Сначала вы прикинулись валенком, а теперь таки признали наличие проблемы

После какой-то дебильной ссылки на булеву алгебру. Сюр.

Ваше число — посчитанная маска, она уже жестко задает выключенные биты. Значит мне придется собрать все кобинации всего чего можно игнорировать и что нельзя и придется перечислять с индивирульаной OR маской

Не придется. Выборка каждого бита это будет каждый раз вполне простой селект. То есть для 64 бит вам придется сделать 64 простых селекта и сделать групп

Еще раз повторю свой вопрос, раз так сложно. Ссылаясь на вашу же фразу — как за одно интовое сравнение сделать AND и OR поиск по маске посчитанной на клиенте?

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

Не придется. Выборка каждого бита это будет каждый раз вполне простой селект. То есть для 64 бит вам придется сделать 64 простых селекта и сделать групп

64 простых селекта? Проржался. Спасибо.

За сим я удаляюсь.

И об этом я сказал в самом начале. Сначала вы прикинулись валенком, а теперь таки признали наличие проблемы

Проблема у вас в голове

64 простых селекта? Проржался. Спасибо.

На здоровье. Это говорит достаточно о вашем опыте

На здоровье. Это говорит достаточно о вашем опыте

О вашем тоже, если вы в первую очередь бежите писать 64 селекта.

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

О вашем тоже, если вы в первую очередь бежите писать 64 селекта.

64 селекта это не сложно. Особенно если это разружает бд в разы

Мой опыт и ваш никто не просил обсуждать.

Ваше число — посчитанная маска, она уже жестко задает выключенные биты. Значит мне придется собрать все кобинации всего чего можно игнорировать и что нельзя и придется перечислять с индивирульаной OR маской

Я что-то не пойму, это опять за тот пример с 8,5,4 надо и 1 не надо? В чем там сложность? Там 2 маски - первая полная, вторая на включение. В результате and числа с полной маской у вас всегда должна получиться маска на включение иначе число не подходит.

Это один оператор

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

Вот тоже вариант кстати. Ибо если отсеить в выборке самый старший бит. То есть все расматриваемые маски будут меньше определенного числа.

Я что-то не пойму, это опять за тот пример с 8,5,4 надо и 1 не надо? В чем там сложность? Там 2 маски - первая полная, вторая на включение. В результате and числа с полной маской у вас всегда должна получиться маска на включение иначе число не подходит.

Речь не о конкретном примере. А о понтенциальной сложности предложенного алгоритма на неизвестном объеме данных.

Неизвестном количестве битов, условий и так далее.

10010000 10011001 11011001

Задачу можно искусственно уложнять сколько угодно

В конце концов вы придете к веренице говна в WHERE части или к 64м (лол) запросам.

Блин

Я не понял немного чё ты пытаешься сказать