Новый форум. Структура базы. Конвертор

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

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

-----
PostgreSQL DBA

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

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

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

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

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

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

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

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

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

-----
Just do it

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

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

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

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

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

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

Вариант 1:

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

Вариант 2:

members_settings
member_id, key, value

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

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

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

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

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

-----
PostgreSQL DBA

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

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

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

(Отредактировано автором: 25 Декабря, 2014 - 20:17:17)

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

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

Why EAV is bad

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.