Нужно ли таблицу users разделять на несколько?

Question

[Александр]

Нужно ли в целях оптимизации разбивать таблицу users на несколько? На данный момент у меня уже около 20 столбцов в данной таблице и скорее всего это количество увеличится ещё раза в 2-3.

Comments

[d-stream]

множественное число п.11 и далее - предположительно подразумевает все-таки множество игр?
тогда как минимум имеет смысл держать таблицу с первичным ключом (игра, юзер) и там уже держать число игр, побед и прочую ерунду.
При необходимости сводного вывода - join'ить, суммировать, группировать

[Александр]

d-stream: ну это да, меня сугубо интересуют таблицы вида: id пользователя - какие-либо его данные

[Александр]

d-stream: понятно, что хранить данные о каждой игре пользователя в таблице с пользователями - откровенно плохое решение.

Answer 1

[Rsa97]

А какая разница, сколько там столбцов, если они реально необходимы? Запрашивайте только нужные и всё.

Comments

[Александр]

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

[ТыжСисАдмин]

LordGuard: Ну так в чем проблема? Создаёте таблицу "Contacts" а в таблице "User" храните id записи.
В общем что к чему, неплохо описано в доках рельсов rusrails.ru/active-record-associations

[Rsa97]

LordGuard: Смотреть надо, что это за данные и как они используются. Если, например, у пользователя может быть несколько телефонных номеров, почтовых и e-mail адресов, то их можно вынести в отдельную таблицу контактов. Если пользователю назначаются различные права, то их можно сделать колонкой с типом SET или, опять же, отдельной связанной таблицей. Но если связь идёт один-к-одному, то делать отдельную таблицу никакого смысла нет.

[ТыжСисАдмин]

Rsa97: в mysql есть подобие views в постгресе? С мускулем давно не работал, не помню.

[Rsa97]

Алексей POS_troi: Есть

Answer 2

[ky0]

Завсисит от того, какие запросы вы собираетесь выполнять по этим данным и сколько они будут весить. В общем случае - одна таблица лучше, т.к. UNION довольно ресурсоёмкая операция.

Answer 3

[d-stream]

А юзеров чуть больше чем пальцев на руках? -)

Имеет смысл бороться со структурой, если там фигурируют tel1, tel2, tel3 и т.п. Точнее не бороться, а нормализовывать.

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

Answer 4

[Захар Сторожук]

Если вам мешает большое количество столбцов и в дальнейшем вы не собираетесь ввести редактирование напрямую из базы, а через интерфейсы(панели управления своим продуктом), то вы можете группировать столбцы. К примеру:
gameCount, winGameCount хранить в одном столбце, в таком виде значений:
"[10, 2]", а сам столбец назвать как gameInformation. Соотвественно вы можете сгруппировать и 10 столбцов, если они описывают один и тот же элемент в вашем продукте.