coylOne 15 авг 2008 в 17:05

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

3 мин

2.5K

Комментарии 25

BugM 15 авг 2008 в 17:12

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

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

coylOne 15 авг 2008 в 17:17

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

BugM 15 авг 2008 в 17:24

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

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

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

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

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

coylOne 15 авг 2008 в 19:33

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

Chrome 28 авг 2008 в 10:33

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

MrButek 15 авг 2008 в 17:17

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

MrButek 15 авг 2008 в 17:20

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

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

coylOne 15 авг 2008 в 17:21

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

coylOne 15 авг 2008 в 17:23

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

bkonst 15 авг 2008 в 17:29

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

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

-1

dkurilenko 15 авг 2008 в 20:55

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

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

dkurilenko 15 авг 2008 в 20:53

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

coylOne 15 авг 2008 в 23:10

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

ISpy 15 авг 2008 в 21:27

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

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

coylOne 15 авг 2008 в 23:09

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

ISpy 15 авг 2008 в 23:11

Где?)

coylOne 15 авг 2008 в 23:15

Mysql 5 с чем-то

ISpy 15 авг 2008 в 23:29

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

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