Есть проблема хранения 3000 переменных

Здравствуйте. Мне очень необходима помощь знающих людей.

Есть проблема хранения 3000 переменных, каждая переменная принимает значение 0 или 1. Данные настройки хранятся в БД.

Я додумался до четырёх решений.
1. Хранить всё как элементы в Массива, серилизовать, сжимать и хранить в БД как текст.
2. Хранить всё как Бинарное число. Редактировать как не знаю.
3. Хранить как Десятичное число. Редактировать как не знаю.
4. Хранить как Строку. Редактировать как строку.
5. Хранить каждую переменную отдельно в БД.
Смог реализовать первый вариант, но получилась строка в 6000 символов. Это очень много, если учесть что первоначально переменных 3000. Первый реализованный вариант мне не нравится, хоть он и является очень простым для работы.

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

Честно говоря я бы воспользовался вариантом номер 5.
БД на то и сеть База Данных, чтобы хранить данные в любом виде и сколько нужно! Тем более 3000 записей для БД - это семечки...
(Добавление)
По поводу скорости - тут уж смотря какой движок используется + кэширование!
Короче тут и скорость работы и размер занимаемой памяти зависит от того, как Вы настроите саму БД!

2 - наиболее предпочтителен к памяти и скорости, 1 - наиболее прост, 4 - тоже не сложно, но не так требователен к памяти, 5 - самый медленный и требовательный к ресурсам

-----
if(time()>1356048000) die();

Мне кажется лутше всего хранить в масиве и не замарачиватся, но если значения могут быть только 0 или 1 то можно зделать одно число (как последовательность бит). Например

-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.

Спасибо за попытку, но не помогло. Написало что "Warning: Cannot use a scalar value as an array in index.php on line 40 "

Идиальный вариант это использовать строку битов, и проводить все манипуляции с ними. Считаю этот вариант самым лучшим как по скорости так и по объёму используемой памяти, но к сожалению возможности работы PHP с бинарными данными нету.

White
Почти полностью согласен. Можете аргументировать позицию почему 5 самый медленный и требовательный??? У меня есть предположения, но хотелось бы знать ваше мнение.

Craken
Читайте внимательнее. 3000 переменных-настроек, а не строк.
Строк там будет over 9000. Соответственно не о какой таблице в 3000 столбцов речи идти не может.
Почему вариант 5??? Считаю что SQL серверу проще будет отдать одну большую ячейку, чем 1000 маленьких. Разве это не так???

http://php.su/learnphp/operators/?bool

Аналогично и сам mysql умеет.

-----
PostgreSQL DBA

Вариант 5 + memcache
В нем хранятся уже сериализованые данные.
Десериализовывается автоматом.
В БД лезть не надо.
Поменять можно любой из 3000 параметров: Достал->Переопределил->Записал.
В базу сбрасывать только для сохранения "настроек".
По умолчанию 64 мБ.
Хватит?

-----
Шта? Репозиторий?

Как вариант использовать noSQL key-value

DeepVarvar
для своего сервера или VPS да, но на хостинге не всегда он есть

-----
if(time()>1356048000) die();

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

-----
Шта? Репозиторий?

Сам задал вопрос сам на него и отвечу.

По скорости работы получается так.
Быстрее
5 – массив с настройками собирается силами PHP при получение ответа от БД
4 – Требуется собирать разбирать строку в массив с настройками.
2-3 – нету простого способа работы с данными.
1 – сериализация-десерилизация данных.
Медленее.

По занимаемому месту в БД
Меньше
2-3 – Биты
5 – биты + нагрузка на создание ячеек.
4 – текстовая строка. ~3кб
1 – сериализованные данные. Больше 168 кб. 
Больше

В итоге первоначальная идея с сериализваным массивом, оказалась самой медленным и прожорливым решением. Разочарован очень сильно.

Нормального решения обработать пункты 2-3, силами PHP, нет. Более того оно ограничено 32 битами.

Решение с хранением в строке, хорошее, но проигрывает чуть-чуть решению с массивом.

Если посмотреть в первое сообщение, то можно заметить что решение использовать БД, пришло в самый последний момент. Тем не менее, остановился на нём.

DeepVarvar
Использовать MemCache для кеширования настроек которые будут использованы один раз в начале рабочей недели. Выглядит как минимум "странно".
Использование MemCache более оправдано, в случае с часто запрашиваемыми данными.

RomAndry
А я то думал реляционные базы всех победили, а нет конкуренты ещё есть...
Спасибо, на будущее обязательно познакомлюсь с решениями NoSql.

Мелкий
Спасибо, почитал. Это как то маловато. Если не ошибаюсь то PHP нет возможности объявить двоичное число. Ну и 32 бита в моём случае совсем не помогут.

Я остановился на варианте 5. Но если у кого будут интересные предложения, за исключением выбрать лучший движок/настроить БД/ использовать полезности/купить мощный сервак, то будут рад почитать.

Nosferatu, мне просто интересно, а зачем 3000 переменных? Что это такое? Просто интересно)

-----
new01