PHP.SU

Программирование на PHP, MySQL и другие веб-технологии
PHP.SU Портал     На главную страницу форума Главная     Помощь Помощь     Поиск Поиск     Поиск Яндекс Поиск Яндекс     Вакансии  Пользователи Пользователи


 Страниц (3): « 1 [2] 3 »   

> Описание: Начало.
Мелкий Супермодератор
Отправлено: 24 Декабря, 2014 - 16:34:13
Post Id



Активный участник


Покинул форум
Сообщений всего: 11906
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 616 раз(а)




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

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


-----
PostgreSQL DBA
 
 Top
DeepVarvar Супермодератор
Отправлено: 24 Декабря, 2014 - 16:53:02
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Мелкий пишет:
лишено смысла, в общем-то
Не лишено - extended-data можно лениво дергать только когда оно понадобятся, а не тащить это в профиль каждый раз. А еще мне просто не нравятся таблицы в стопицот полей ))
 
 Top
DeepVarvar Супермодератор
Отправлено: 24 Декабря, 2014 - 19:40:28
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Так как всетаки делать то? Редко используемых данных будет достаточно, и все они будут разных типов, в основном (пока вижу) интовые, может некоторые ENUM.
 
 Top
Bio man
Отправлено: 24 Декабря, 2014 - 20:07:18
Post Id


Постоянный участник


Покинул форум
Сообщений всего: 2751
Дата рег-ции: Июль 2010  
Откуда: Даугавпилс, Латвия


Помог: 52 раз(а)




может varchar? в отличии от char, varchar не резервирует память. и вполне вместителен.
(Добавление)
и на 1 байт меньше аналогичного text
 
 Top
DeepVarvar Супермодератор
Отправлено: 25 Декабря, 2014 - 14:45:29
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Не пойму зачем писать числа в чаровые поля.
 
 Top
Panoptik
Отправлено: 25 Декабря, 2014 - 15:50:51
Post Id



Постоянный участник


Покинул форум
Сообщений всего: 2493
Дата рег-ции: Нояб. 2011  
Откуда: Одесса, Украина


Помог: 131 раз(а)




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

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


-----
Just do it
 
 Top
Bio man
Отправлено: 25 Декабря, 2014 - 17:29:20
Post Id


Постоянный участник


Покинул форум
Сообщений всего: 2751
Дата рег-ции: Июль 2010  
Откуда: Даугавпилс, Латвия


Помог: 52 раз(а)




Как насчёт MongoDB или другой альтернативной NoSQL БД?
(Добавление)
имеется ввиду для настроек а не для всего и вся
 
 Top
DeepVarvar Супермодератор
Отправлено: 25 Декабря, 2014 - 17:47:51
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




А смысл в монге? Все настройки одноуровневые вида ключ-значение, все совершенно спокойно вписывается в простую таблицу в БД.
 
 Top
Bio man
Отправлено: 25 Декабря, 2014 - 17:51:42
Post Id


Постоянный участник


Покинул форум
Сообщений всего: 2751
Дата рег-ции: Июль 2010  
Откуда: Даугавпилс, Латвия


Помог: 52 раз(а)




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

Так как ты решил хранить в таблице? Или не решил? Вариантов не много, наверно все уже озвучили.
 
 Top
DeepVarvar Супермодератор
Отправлено: 25 Декабря, 2014 - 17:59:29
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




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

Вариант 1:

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

Вариант 2:

members_settings
member_id, key, value

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

Второй вариант смущает меня тем, что неизвестно, данные какого типа нужно будет хранить.
А если учесть как Мелкий реагирует даже на отсутствие UNSIGNED у интовых, то тут и ему не понравится.
Хотя сам вариант как решение вполне не плох, доставит удобство не лазить в БД для добавления поля.
Но обвязку то для работы с такой таблицей всеравно придется писать.
 
 Top
Мелкий Супермодератор
Отправлено: 25 Декабря, 2014 - 19:21:01
Post Id



Активный участник


Покинул форум
Сообщений всего: 11906
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 616 раз(а)




DeepVarvar пишет:
то тут и ему не понравится.

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

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


-----
PostgreSQL DBA
 
 Top
DeepVarvar Супермодератор
Отправлено: 25 Декабря, 2014 - 19:28:24
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Мелкий пишет:
огромная куча неактивных учёток с настройками по-умолчанию не занимает никакого места
Буквально недавно делал такую доп таблицу с первым вариантом, где данные в ней меняются по REPLACE INTO, т.е. так же не хранятся лишние неактивные пользаковские настройки.
(Добавление)
Мелкий, еще кстати. В новой структуре форума можно заметить что подфорумы отсутствуют.
Хотя в текущей версии подворумы "виртуальные" и просто имеют привязку к форумам, а ссылки в браузере, что на форум что на подфорум - одинаковые.
 
 Top
tuareg
Отправлено: 25 Декабря, 2014 - 20:07:29
Post Id


Участник


Покинул форум
Сообщений всего: 1234
Дата рег-ции: Июнь 2010  


Помог: 69 раз(а)




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

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

 
 Top
DeepVarvar Супермодератор
Отправлено: 26 Декабря, 2014 - 02:41:42
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Я таки EAV какраз не предлагаю, нафик эта помойка.
 
 Top
EuGen Администратор
Отправлено: 29 Декабря, 2014 - 18:22:50
Post Id


Профессионал


Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007  
Откуда: Berlin


Помог: 707 раз(а)






-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
 
 Top
Страниц (3): « 1 [2] 3 »
Сейчас эту тему просматривают: 1 (гостей: 1, зарегистрированных: 0)
« Колонка администратора »


Все гости форума могут просматривать этот раздел.
Только зарегистрированные пользователи могут создавать новые темы в этом разделе.
Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
 



Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB