Упаковка булевых переменных для хранения и поиска в базе

[BugM]

За такое хранение расстрел на месте.
Через год вспомнить что там и как лежит будет невозможно.
Хорошо если документация будет. А если потеряется?

Если нужно 30 полей, пускай будет 30 полей.
Кому они мешают? Пускай лежат себе, с нормальными названиями, комментариями к полям. Никакой документации не нужно и так понятно откуда что брать.

[coylOne]

ну про расстрел за такое хранение не знаю, а вот за потерю документации — точно расстрел =).
Что где лежит можно (я так делаю) описать в конфиге. Оттуда берутся расшифровки для значений (например из массив).
Ну 30 полей хранить тоже можно, это выбор каждого. Я не претендую на абсолютную истину, но ИМХО, такой метод вполне жизнеспособный и (опять же ИМХО) достаточно изящный.

[BugM]

Документация теряется элементарно. Проект сделан, сдан. Контора сделавшая его исчезла.
На доделывание отдали другой. Шанс найти документацию стремится к 0.

Ага, надо знать что конфиг есть, и что оно в нем описано. На поиски в лучшем случае день уйдет. Скорее 2-3 дня.

Зачем плодить таки сложности буквально на пустом месте.
Кому мешают это 30 полей? Винты сейчас вообще ничего не стоит. Ограничений на количество столбцов в таблице можно считать что нет.

И что мы выигрываем от такого хранения?

Минусы понятны сразу:
— Непонятная БД
— Непонятное приложение
— Сложный код и там и там
— Необходима внешняя документация
— Тормоза в перспективе

[coylOne]

Этот подход применим при множественном выборе. Например, если нам надо указать несколько величин одной переменной.

[Chrome]

Есть один минус, максимальная ширина таблицы в mysql составляет 255 поле(к сожалению сам сталкивался с таким).

[MrButek]

А как же SET? Данные типа SET в MySQL тоже хранятся в виде битовых массивов.

[MrButek]

В этом случае поиск будет осуществляться так:

SELECT * FROM tbl WHERE FIND_IN_SET('value', flags);

[coylOne]

Безусловно, можно хранить в SET, но на сколько мне известно, не все СУБД его поддерживают.

[coylOne]

Собственно, мой способ — это и есть реализация SET. Почти уверен, что там так и реализуется поиск.

[bkonst]

> ИМХО, побитовые операции нативны для процессора и должны летать.

Есть такая штука — индексы. При их использовании сложность поиска в базе составляет, грубо говоря, O(log N). Без их использования — O(N). Порядок проигрыша в скорости поиска в такой базе на, скажем, миллионе записей ~100'000 раз. Вы еще хотите пользоваться нативными битовыми операциями в полях, по которым возможна выборка?

[dkurilenko]

в случае использование индекса bitmask даже меньше логарифма.

Вот тут можно почитать www.mysqlperformanceblog.com/2008/04/23/efficient-boolean-value-storage-for-innodb-tables/#comments

[dkurilenko]

нативные то они нативные — но здесь придется д елать фулскан сначало.
Посмотрите в сторону индексов типа bitmask для отдельно стоящих полей-битов — я думаю разница будет громадная.

[coylOne]

дадада. я уже почитал. Спасибо всем.

[ISpy]

На счет запроса «SELECT * FROM t WHERE field & 2 != 0» — удивила запись !=, на сколько мне известно в mysql это не работает, а в ms sql не стандартно и возможно тоже не работает или работает не везде :)

Откуда такая запись «не равно»? Мне просто интересно из какой БД )

[coylOne]

Всё прекрасно работает. Даже специально только что проверил SELECT 1!=2 возвращает 1

[ISpy]

Где?)

[coylOne]

Mysql 5 с чем-то

[ISpy]

Сдаюсь. Тоже только что проверил.
Не знаю, когда-то попытался использовать != и вылетела ошибка, с тех пор всегда юзаю <>.
И не те справочники видимо читаю, когда-то смотрел список операторов MySQL, там не было !=.

Не прав, каюсь :)

[coylOne]

да ладно вам =) велика беда =)

[GMM]

Зачем писать bindec('1'.str_repeat('0',$val-1));
если можно просто 1 << ($val-1)?

[coylOne]

Точняк. Как я мог забыть. Спасибо огромное

[Ventura]

Не в обиду будет сказано, но мне кажется вы изобретаете велосипед. Во всяком случае в PHP.
ru.php.net/pack

[Ventura]

Упс. Кажется, я поторопился. pack не поддерживает boolean.
Сорри.

[malek]

А вот есть такой тип данных BIT в MySQL. Почему им нельзя обойтись?