Конкретная идея: организация ввода и выбора графика сотрудника. Например, есть Вася, он работает по понедельникам и средам, Петя: вторник, четверг и т.д.

Удобно это сделать (имхо) в виде двоичного числа 00000000, где каждый знак будет означать конкретный день недели, скажем, 01001000 - вторник, пятница (слева направо). Естественно, что в десятичной системе это числа 1,2,4,8,16,32,64,128 и их суммы.

Только я не знаю как это сделать в Access :) Если программировать где-то еще, то для проверки значений нужно всего лишь _логически_ перемножить имеющееся число (кстати, ведь до этого его нужно в базу вставить именно как бинари, или же можно обычным?) на условие проверки: If A = Const * A then ... Т.е. при проверке на вторник получим:


Вот. Может быть, что-то похожее уже кто-нибудь реализовывал? (посмотрел форум, но не нашел)

That's all folks...

Ознакомился с темой, большое спасибо Again , Victosha и Rafa .

Возникает вопрос, а стоит ли игра свеч? Я хочу сказать, что для работы с битами в качестве булевых значений придется писать свои обработчики для составления запросов SQL, а также для каждой формы/модуля свои процедуры "упаковки" данных в одно поле (в смысле оптимизировать все формы под такую работу).

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

При сложившихся обстоятельствах, а именно намечающийся в самое ближайшее время переход от MDB к ADP + MSSQL, а также не очень большая интенсивность работы (менее 10.000 записей в сутки от 15 пользователей), мне хочется ознакомиться с методом, попробовать его, но внедрять в проект с потерей времени и возможными (лишними) проблемами в будущем - нет. В конце концов, 8 байт или 1 для современных машин объем не критичный.

P.S. Если бы кто-нибудь сказал свое мнение, как если бы сам выбирал себе, что мол, мужик, дело того стоит или не стоит, я был бы очень признателен.

That's all folks...

Ну, не знаю, если дискуссия по поводу места, то лично мне кажется, что никакая база данных не сможет отдельно хранить один бит информации. В смысле на носителе или памяти, разве что каким-то хитрым образом она на низком уровне упаковываются в один байт (во чушь несу, аж самому интересно).

Машина же не может думать битами, но как нас давно учили на информатике, машинными словами, а это даже не байт. Впрочем, тут мои познания ограничиваются словами Аксемблер и Сиу (взято из анкет соискателей на должность системного администратора :)

Я сейчас делаю небольшую тестовую базку только для того, чтобы выяснить удобство работы с такими вещами. Пока все идет гладко: вставлять значения по набору checkbox'ов легко, правильно отображать их в зависимости от аккумулированного битового значения тоже легко, делать запрос по определенным битам опять легко. Кроме того, это просто интересно :)

P.S. Но работать с отдельными битовыми полями в таблице еще легче! :)

That's all folks...

1 байт ,

Мы не о том говорим :)

Я доделал тестовую базу с одной таблицей (2 поля: id, и число) и формой для работы. У формы меняется рекордсет по условию, составленному из семи чекбоксов (дни недели), а именно запросом через предлагаемую здесь функцию из модуля (a And b).

Все работает великолепно, но связываться я не буду - нет смысла городить такое для простого графика. Так что будет в таблице еще 7 булинов и все (правда, выглядит сильно громоздко :о).

P.S. Но метод взят на вооружение и при случае будет, вашими стараниями, использован.

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

Дабы разобраться, что все таки происходит с MDB в плане размера, в случае разных полей в таблицах, провел такое исследование: добавление в базу 100 000 и 1 000 000 записей программным путем с засечением времени и сравнением получившегося размера баз. При этом интерес представляли три случая:

1. База с таблицей из поля типа byte .
2. База с таблицей из поля типа boolean .
3. База с таблицей из восьми полей типа boolean (в сумме это должно было быть похоже на байт :).

Итак результаты размера:



* база с байтом изначально была меньше на ровно 4КБ, так и осталась!
* количество кода для вставки через CurrentDb.Execute ("INSERT INTO..., естественно, было разным во всех случаях.


Разница - 0, 0%, нуль!!!

Размер итоговой базы во всех трех случаях одинаков!


ВЫВОД:

Поправьте меня, если я ошибаюсь, но получается, что Access постоянно резервирует пространство базы под абсолютно все объекты, будь то, код, кнопки, таблицы, поля и т.д. Я думаю, что для кода VBA минимальный объем "кластера" - те самые 4 КБ (кстати, по-моему довольно удачное сравнение с файловой системой). Но что при этом происходит при резервировании места под данные? Один миллион записей по одному байту это, грубо, один мегабайт. Счетчик (ключевое поле) длинной в 4 байта это еще 4 МБ. Но в итоге то у нас 23 МБ! Куда оно пошло? Скорее всего, на резервирование.

Если Access (говоря про Access я здесь все время имею в виду JET :) работает страницами-кластерами, т.е., если предположить, что запись в любой таблице из любого количества полей не может быть меньше определенного объема, то этот объем легко посчитать - 23 МБ / 1 млн. = 23 байт, вместо нужных пяти! Какое расточительство! :)

К сожалению, я не знаю механики работы Access/JET, поэтому эти измышления могут являться лишь банальной истиной, которую все давно знают (или быть полным бредом :).




Ну, наконец, скорость добавления этих записей (AthlonXP 3200+):



Поле (число) типа байт добавляется быстрее логического! А 8 логических полей дают перекур аж на 25 процентов длиннее!

Вполне может быть, что работа с записями, в которых логические поля "упакованы", даже с учетом затрат на обработку кодом, будет идти быстрее native режима Access.

P.S. 25 минут на 1 000 000 записей... Долго же еще нам не будет хватать мощности "железа" :)

That's all folks...