Как стать автором
Обновить

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

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

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

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

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

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

Минусы понятны сразу:
— Непонятная БД
— Непонятное приложение
— Сложный код и там и там
— Необходима внешняя документация
— Тормоза в перспективе
Этот подход применим при множественном выборе. Например, если нам надо указать несколько величин одной переменной.
Есть один минус, максимальная ширина таблицы в mysql составляет 255 поле(к сожалению сам сталкивался с таким).
А как же SET? Данные типа SET в MySQL тоже хранятся в виде битовых массивов.
В этом случае поиск будет осуществляться так:

SELECT * FROM tbl WHERE FIND_IN_SET('value', flags);
Безусловно, можно хранить в SET, но на сколько мне известно, не все СУБД его поддерживают.
Собственно, мой способ — это и есть реализация SET. Почти уверен, что там так и реализуется поиск.
> ИМХО, побитовые операции нативны для процессора и должны летать.

Есть такая штука — индексы. При их использовании сложность поиска в базе составляет, грубо говоря, O(log N). Без их использования — O(N). Порядок проигрыша в скорости поиска в такой базе на, скажем, миллионе записей ~100'000 раз. Вы еще хотите пользоваться нативными битовыми операциями в полях, по которым возможна выборка?
нативные то они нативные — но здесь придется д елать фулскан сначало.
Посмотрите в сторону индексов типа bitmask для отдельно стоящих полей-битов — я думаю разница будет громадная.
дадада. я уже почитал. Спасибо всем.
На счет запроса «SELECT * FROM t WHERE field & 2 != 0» — удивила запись !=, на сколько мне известно в mysql это не работает, а в ms sql не стандартно и возможно тоже не работает или работает не везде :)

Откуда такая запись «не равно»? Мне просто интересно из какой БД )
Всё прекрасно работает. Даже специально только что проверил SELECT 1!=2 возвращает 1
Где?)
Mysql 5 с чем-то
Сдаюсь. Тоже только что проверил.
Не знаю, когда-то попытался использовать != и вылетела ошибка, с тех пор всегда юзаю <>.
И не те справочники видимо читаю, когда-то смотрел список операторов MySQL, там не было !=.

Не прав, каюсь :)
да ладно вам =) велика беда =)
Зачем писать bindec('1'.str_repeat('0',$val-1));
если можно просто 1 << ($val-1)?
Точняк. Как я мог забыть. Спасибо огромное
НЛО прилетело и опубликовало эту надпись здесь
Не в обиду будет сказано, но мне кажется вы изобретаете велосипед. Во всяком случае в PHP.
ru.php.net/pack
Упс. Кажется, я поторопился. pack не поддерживает boolean.
Сорри.
А вот есть такой тип данных BIT в MySQL. Почему им нельзя обойтись?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории