Не. text слишком много. Там же основное количество данных - несколько символов.

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

Не лишено - extended-data можно лениво дергать только когда оно понадобятся, а не тащить это в профиль каждый раз. А еще мне просто не нравятся таблицы в стопицот полей ))

Так как всетаки делать то? Редко используемых данных будет достаточно, и все они будут разных типов, в основном (пока вижу) интовые, может некоторые ENUM.

может varchar? в отличии от char, varchar не резервирует память. и вполне вместителен.
(Добавление)
и на 1 байт меньше аналогичного text

Не пойму зачем писать числа в чаровые поля.

ок, не нравится текст или чар делаешь 3 поля
intValue, charValue, textValue вместо предложенного мною обычного универсального value

выиграешь от этого не много но волосы на ж.. рвать перетанешь

Как насчёт MongoDB или другой альтернативной NoSQL БД?
(Добавление)
имеется ввиду для настроек а не для всего и вся

А смысл в монге? Все настройки одноуровневые вида ключ-значение, все совершенно спокойно вписывается в простую таблицу в БД.

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

Так как ты решил хранить в таблице? Или не решил? Вариантов не много, наверно все уже озвучили.

Да, я решил хранить в таблице.
Но не решил в какой.

Вариант 1:

members_settings
member_id, field1, field2, field3 ... fieldN

Вариант 2:

members_settings
member_id, key, value

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

Второй вариант смущает меня тем, что неизвестно, данные какого типа нужно будет хранить.
А если учесть как Мелкий реагирует даже на отсутствие UNSIGNED у интовых, то тут и ему не понравится.
Хотя сам вариант как решение вполне не плох, доставит удобство не лазить в БД для добавления поля.
Но обвязку то для работы с такой таблицей всеравно придется писать.

Сюрприз: я сам на работе делал именно такую структуру user-key-value
Потом команда от неё отказалась и я так и не понял аргументацию, почему.
Если решение имеет обоснованную аргументацию - ничего не имею против. Как уже писал, важно, чтобы можно было это решение заменить без изменения всего остального кода.

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

Буквально недавно делал такую доп таблицу с первым вариантом, где данные в ней меняются по REPLACE INTO, т.е. так же не хранятся лишние неактивные пользаковские настройки.
(Добавление)
Мелкий, еще кстати. В новой структуре форума можно заметить что подфорумы отсутствуют.
Хотя в текущей версии подворумы "виртуальные" и просто имеют привязку к форумам, а ссылки в браузере, что на форум что на подфорум - одинаковые.

То что описывается это "классический" EAV. Плюсы минусы понятны.
Можно как вариант, для каждого типа(int, varchar и т.д) завести свою табличку.
+ : Данные имеют свой тип
- : Сколько типов == столько таблиц, если мы не знаем какой тип имеет настройка, долбим все таблицы по очереди, пока не найдем нужную настройку
По идее индекс нужен только на id_user+key
Также возможно рассмотреть вариант с вьюхами mysql. Сразу говорю, я с ними не работал, и пока не понимаю механизм как они работают. Но если у MySQL с ними все хорошо, то это будет выход.
*не понимаю механизм как они работают-> В плане нагрузок и т.д

Я таки EAV какраз не предлагаю, нафик эта помойка.

Why EAV is bad