Стоит ли выность настройки пользователя в другую таблицу?

Question

[entermix]

Сайт на Kohana 3.3, используется ORM

Есть примерно такая таблица users:

id, login, first_name, last_name, email, phone, vkontakte, facebook, twitter, etc .... *

где "*" это штук 15 (в плане больше) ячеек tinyint(1), например:

- разрешить отправку смс клиентам
-- отправлять смс клиентам после события 1
--- в случае 1
--- в случае 2
--- в случае 3
- отправлять смс клиентам после события 2
--- в случае 1
--- в случае 2
- отправлять смс клиентам после события 3
--- в случае 1

И так далее..

Каждый аккаунт может быть как поставщиком, так и клиентом (даже одновременно). Прикол в том, что все эти настройки нужны только определенной группе пользователей, т.е. поставщикам

Получается, что независимо от того пользователь клиент, или поставщик, Kohana ORM тащит в каждом запросе с таблицы users всю инфу (в том числе и ту, что актуальна только для поставщика)

Стоит ли выностить все эти настройки в другую таблицу и связывать ее с аккаунтом пользователя? или такие запросы (даже если они длинные) не приносят сильную нагрузку на БД?

Просто уже есть куча моделей ORM, не хотелось бы делать еще несколько под настройки

Answer 1

[asdz]

Так это же почти не на что не влияет, столбцы быстро выбираются. Если конечно у вас там не миллионы записей и вы их не все за раз читаете... Зато потом прибавится работы по соединению профиля пользователя с его учеткой, вот это будет точно медленнее выполняться чем простой селект.

Comments

[Андрей]

2 селекта по индексам будут выполняться ничуть не дольше, когда база разрастется до гигабайт (а с таким составом полей она может быстро разрастись). Да и соединить - это вообще не проблема. Пара лишних миллисекунд (если не меньше) ничего не решит.

[asdz]

Андрей: Просто не понятно, какая проблема решается выносом этих полей в отдельную таблицу? А если проблемы нет как таковой, то зачем ее решать?

[Андрей]

asdz: Когда в большой таблице меньше полей - она и весит меньше, и искать/обрабатывать проще.. в любом случае это даст прирост производительности в хайлоаде, если он будет иметь место.. а если же планируется таблица а 2-3к записей, то конечно заморачиваться не надо :)

[entermix]

asdz: просто хотел узнать, как сделать лучше, чтобы в будущем не решать проблему, если она появится)

Просто эти настройки (например рассылки по смс) будут использованы лишь при рассылке смс клиентам этого пользователя.

А что если сделать эти настройки в виде массива, затем сериализировать его, и записать в БД всего в 1 ячейку?

[asdz]

entermix: Это самый плохой вариант, даже не рассматривайте его. Боятся null ячеек не надо, плохого они ничего не сделают

[entermix]

А почему это самый плохой вариант? :)

[asdz]

entermix: Как потом будете делать запросы к сериализованным данным?

[entermix]

asdz: Как таковы запросы к ним мне ну нужны, сделал так: при сохранении объекта "Пользователь", информация сериализируется, и сохраняется в БД, в модели так-же добавил функциию, которая возвращает эту инфу в виде ассоциативного массива, если мне нужно узнать например включена ли смс рассылка, делаю так: if (Arr::get($user->get_sms_mailing_settings, 'allow')) {..} else {..}, если пользователь закрыл заказ, и нам нужно знать нужно ли осуществлять рассылку: if (Arr::get($user->get_sms_mailing_settings, 'allow') && Arr::get($user->get_sms_mailing_settings, 'orders.close')){..} else {..}

[asdz]

Как вы будете делать сортировку, отбор по сериализованным полям? выдирать все записи, а потом заниматься вот таким перебором? Размещения этих полей в одной таблице или вынос в другую - оба способа хороши, потому что все это понимает орм, sql и не ухудшает производительность, а вот в этом случае орм вы выкидываете, выкидываете и бд, потому что она не работает с вашими сериализованными данными. Я не советовал использовать расщепление сущности только для удобства, потому что надо описывать связи, соблюдать целостность внешних ключей и так далее, но плюсов это особо никаких не дает, это микрооптимизация.

Answer 2

[Андрей]

вопрос спорный
но я бы вынес в отдельную