Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737 Форумы портала PHP.SU :: Новый форум. Структура базы. Конвертор [2]
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
Не. text слишком много. Там же основное количество данных - несколько символов.
По самому вопросу - или в одну таблицу (или 1:1 связь делать, что лишено смысла, в общем-то) или такая вот таблица настроек. Не могу выделить превалирующих плюсов у обоих подходов.
В общем-то, если модель даёт только интерфейс "дай значение такой-то настройки" - то конкретная реализация не имеет значения, к ней привязан только код непосредственно модели.
----- PostgreSQL DBA
DeepVarvar
Отправлено: 24 Декабря, 2014 - 16:53:02
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
Мелкий пишет:
лишено смысла, в общем-то
Не лишено - extended-data можно лениво дергать только когда оно понадобятся, а не тащить это в профиль каждый раз. А еще мне просто не нравятся таблицы в стопицот полей ))
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
Так как всетаки делать то? Редко используемых данных будет достаточно, и все они будут разных типов, в основном (пока вижу) интовые, может некоторые ENUM.
Первый вариант смущает некоторых из вас тем, что при необходимости новой настройки нужно будет добавить еще одно поле.
В остальном он не будет иметь недостатков - вешай любые индексы, определяй тип поля и пр..
Второй вариант смущает меня тем, что неизвестно, данные какого типа нужно будет хранить.
А если учесть как Мелкий реагирует даже на отсутствие UNSIGNED у интовых, то тут и ему не понравится.
Хотя сам вариант как решение вполне не плох, доставит удобство не лазить в БД для добавления поля.
Но обвязку то для работы с такой таблицей всеравно придется писать.
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
DeepVarvar пишет:
то тут и ему не понравится.
Сюрприз: я сам на работе делал именно такую структуру user-key-value
Потом команда от неё отказалась и я так и не понял аргументацию, почему.
Если решение имеет обоснованную аргументацию - ничего не имею против. Как уже писал, важно, чтобы можно было это решение заменить без изменения всего остального кода.
Основные минусы - не выйдет внешние ключи вешать (кроме собственно юзера), необходимость использования неоптимального типа данных, значения по-умолчанию должна знать модель данных.
Плюсы: удобно хранить много необязательных опций, огромная куча неактивных учёток с настройками по-умолчанию не занимает никакого места.
----- PostgreSQL DBA
DeepVarvar
Отправлено: 25 Декабря, 2014 - 19:28:24
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
Мелкий пишет:
огромная куча неактивных учёток с настройками по-умолчанию не занимает никакого места
Буквально недавно делал такую доп таблицу с первым вариантом, где данные в ней меняются по REPLACE INTO, т.е. так же не хранятся лишние неактивные пользаковские настройки. (Добавление) Мелкий, еще кстати. В новой структуре форума можно заметить что подфорумы отсутствуют.
Хотя в текущей версии подворумы "виртуальные" и просто имеют привязку к форумам, а ссылки в браузере, что на форум что на подфорум - одинаковые.
Покинул форум
Сообщений всего: 1234
Дата рег-ции: Июнь 2010
Помог: 69 раз(а)
То что описывается это "классический" EAV. Плюсы минусы понятны.
Можно как вариант, для каждого типа(int, varchar и т.д) завести свою табличку.
+ : Данные имеют свой тип
- : Сколько типов == столько таблиц, если мы не знаем какой тип имеет настройка, долбим все таблицы по очереди, пока не найдем нужную настройку
По идее индекс нужен только на id_user+key
Также возможно рассмотреть вариант с вьюхами mysql. Сразу говорю, я с ними не работал, и пока не понимаю механизм как они работают. Но если у MySQL с ними все хорошо, то это будет выход.
*не понимаю механизм как они работают-> В плане нагрузок и т.д
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.