Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
14.10.2016, 05:40
|
|||
|---|---|---|---|
|
|||
Стоит ли разбивать таблицу на две? |
|||
|
#18+
Всем привет. Требуется ответ специалистов. В данный момент имеется таблица users, в которой содержаться поля с логином, именем, фамилией, почтой, полом и прочая стандартная инфа. Также имеются множество полей с различными настройками для юзеров, таких полей с настройками планируется примерно 20-30, может и больше. Хранимые значения там будут совсем короткие, не более 10 символов в каждом. Обновлять настройки как мне кажется пользователи будут не часто. Вот появилась мысль личные данные пользователей оставить в таблице users, а вот настройки пользователей вынести в таблицу settings, быть может ещё и связать их внешним ключом по id Уважаемые специалисты, подскажите, стоит ли выносить настройки в отдельную таблицу и нужно ли их связывать внешним ключом? С внешними ключами вообще никогда не работал, но погуглив понял, что в данном случае их было бы полезно применить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.10.2016, 05:44
|
|||
|---|---|---|---|
|
|||
Стоит ли разбивать таблицу на две? |
|||
|
#18+
Забыл добавить, если это важно конечно. Таблицы InnoDB ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.10.2016, 09:59
|
|||
|---|---|---|---|
Стоит ли разбивать таблицу на две? |
|||
|
#18+
Gamletus... стоит ли выносить настройки в отдельную таблицу и нужно ли их связывать внешним ключом? Если вы не знаете количество настроек (или в ближайшем будущем оно изменится) - выносите. Да, стоит (у вас стандартный EAV - гуглите и читайте). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.10.2016, 16:10
|
|||
|---|---|---|---|
|
|||
Стоит ли разбивать таблицу на две? |
|||
|
#18+
Я ещё хотел уточнить, т.к. пока гуглил, нашёл ситуацию чем-то похожую, но там выносили в отдельную таблицу, когда для одного пользователя создавалось несколько строк с данными (именно строк). У меня же как в таблице users, так и в таблице settings будет строго по одной строке для каждого пользователя. А вот количество столбцов в settings будет примерно 20-30... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.10.2016, 16:25
|
|||
|---|---|---|---|
|
|||
Стоит ли разбивать таблицу на две? |
|||
|
#18+
GamletusУ меня же как в таблице users, так и в таблице settings будет строго по одной строке для каждого пользователя. А вот количество столбцов в settings будет примерно 20-30... Это плохой дизайн. Заверни все настройки в JSON и храни в одном поле таблицы users. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.10.2016, 18:05
|
|||
|---|---|---|---|
|
|||
Стоит ли разбивать таблицу на две? |
|||
|
#18+
Dimitry SibiryakovЭто плохой дизайн. Заверни все настройки в JSON и храни в одном поле таблицы users.Идея хорошая, но мне кажется будет сложновато при добавлении каких-то новых настроек так, чтобы они добавились сразу у всех пользователей без лишних заморочек. Когда каждая настройка хранится в отдельном столбце, то вроде как добавил новый столбец и всё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.10.2016, 18:55
|
|||
|---|---|---|---|
|
|||
Стоит ли разбивать таблицу на две? |
|||
|
#18+
Gamletusно мне кажется будет сложновато при добавлении каких-то новых настроек так, чтобы они добавились сразу у всех пользователей без лишних заморочек. А зачем их добавлять всем пользователям сразу? Если какой-то настройки в БД нет - используй умолчательное значение для неё. Не вижу никакой проблемы с этим. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.10.2016, 19:17
|
|||
|---|---|---|---|
Стоит ли разбивать таблицу на две? |
|||
|
#18+
Gamletusвот количество столбцов в settings будет примерно 20-30... хм... а я бы сделал всего четыре колонки: id, settingKey, settingValue и userId ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.10.2016, 21:51
|
|||
|---|---|---|---|
Стоит ли разбивать таблицу на две? |
|||
|
#18+
GamletusИдея хорошая, но мне кажется будет сложновато при добавлении каких-то новых настроек так, чтобы они добавились сразу у всех пользователей без лишних заморочек. Когда каждая настройка хранится в отдельном столбце, то вроде как добавил новый столбец и всё. новый столбец в таблице это не всё, это только начало, за этим обычно идет изменение интерфейса, средств выборки и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.10.2016, 12:14
|
|||
|---|---|---|---|
Стоит ли разбивать таблицу на две? |
|||
|
#18+
GamletusВот появилась мысль личные данные пользователей оставить в таблице users, а вот настройки пользователей вынести в таблицу settings, быть может ещё и связать их внешним ключом по id Уважаемые специалисты, подскажите, стоит ли выносить настройки в отдельную таблицу и нужно ли их связывать внешним ключом?Если это настройки "для всех", если нет разделения пользователей на некие типы, если это не "пользовательские" настройки, которые сами пользователи могут добавлять когда захотят, то зачем вообще такие сложности, зачем такой дизайн с EAV? В СУБД уже есть средства управления полями таблиц, связями, констрейнами, индексация, и.т.д, зачем создавать дополнительные, свои, разве есть надежда сделать их лучше, чем то, что уже имеется в СУБД? Используйте просто обычные поля в таблице. Вопрос - выносить ли это в отдельную таблицу. Если это некая отдельная сущность, которая будет использоваться независимо, ну, тогда можно выделить в отдельную таблицу. Связывать 1=1 с юзерами - зависит от того, может ли "настройка пользователя" управляться отдельно от пользователя (например, будет настройка "оператор", и все пользователи операторы работают с этой настройкой). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.10.2016, 13:55
|
|||
|---|---|---|---|
Стоит ли разбивать таблицу на две? |
|||
|
#18+
skyANAGamletusвот количество столбцов в settings будет примерно 20-30... хм... а я бы сделал всего четыре колонки: id, settingKey, settingValue и userId+1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.10.2016, 17:21
|
|||
|---|---|---|---|
|
|||
Стоит ли разбивать таблицу на две? |
|||
|
#18+
Два дня тестировал все предложенные варианты и всё-таки решил не выносить в отдельную таблицу, решил делать каждый тип настроек в отдельном столбце. Но однозначно решил делать кеш в виде файла для каждого пользователя, завернув пхпшной функцией json_encode/json_decode, чтобы понапрасну в базу не обращался. Как-то так )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.10.2016, 09:10
|
|||
|---|---|---|---|
Стоит ли разбивать таблицу на две? |
|||
|
#18+
Dimitry SibiryakovGamletusУ меня же как в таблице users, так и в таблице settings будет строго по одной строке для каждого пользователя. А вот количество столбцов в settings будет примерно 20-30... Это плохой дизайн . Заверни все настройки в JSON и храни в одном поле таблицы users. Поэтому предлагаешь еще более плохой ??? Справочник пользователей никогда не бывает очень большим, поэтому 20-30 полей-настроек никак не повлияет на производительность. Как вариант - прикрутить что-то вроде EAV. Пригодиццо не только для пользователей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.10.2016, 09:24
|
|||
|---|---|---|---|
|
|||
Стоит ли разбивать таблицу на две? |
|||
|
#18+
Если настроек будет до 30, и есть надежда, что их количество со временем устаканится, то вполне допустимо будет добавить 30 полей в таблицу users и не мучиться. Выделять отдельную таблицу со связью 1:1 никакого смысла нет. Если же предполагается, что регулярное выдумывание и добавление новых настроек для пользователей - нормальное явление в жизни БД - тогда да, можно EAV. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.10.2016, 13:36
|
|||
|---|---|---|---|
Стоит ли разбивать таблицу на две? |
|||
|
#18+
Dimitry SibiryakovЭто плохой дизайн. Заверни все настройки в JSON и храни в одном поле таблицы users.нормальные формы теперь не модны? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.10.2016, 13:54
|
|||
|---|---|---|---|
|
|||
Стоит ли разбивать таблицу на две? |
|||
|
#18+
Cane Cat FisherЕсли же предполагается, что регулярное выдумывание и добавление новых настроек для пользователей - нормальное явление в жизни БД - тогда да, можно EAV.Количество настроек однозначно устаканится )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.10.2016, 20:06
|
|||
|---|---|---|---|
Стоит ли разбивать таблицу на две? |
|||
|
#18+
Чтобы понять стоит ли разносить данные по разным таблицам я смотрю как часто меняются данные и их зависимость друг от друга. У меня, например, логины-пароли вынесены в отдельную таблицу- это явно независящие от остальных настроек данные, а настройки системы хранятся в EAV- очень легко добавлять новые настройки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.10.2016, 07:39
|
|||
|---|---|---|---|
Стоит ли разбивать таблицу на две? |
|||
|
#18+
GamletusДва дня тестировал все предложенные варианты и всё-таки решил не выносить в отдельную таблицу, решил делать каждый тип настроек в отдельном столбце. Но однозначно решил делать кеш в виде файла для каждого пользователя, завернув пхпшной функцией json_encode/json_decode, чтобы понапрасну в базу не обращался. Как-то так )) ты очень много думаешь. сделай хоть как-то. на самом деле нет смысла делить на две таблицы если у тебя строго 1:1 и новые настройки не будут добавляться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.10.2016, 13:22
|
|||
|---|---|---|---|
|
|||
Стоит ли разбивать таблицу на две? |
|||
|
#18+
MasterZivты очень много думаешь.Потому, что если заранее много не подумать, то потом приходится много переделывать )) да и время позволяет никуда не спешить. MasterZivсделай хоть как-то.Хоть как-то - это точно не для меня. MasterZivна самом деле нет смысла делить на две таблицы если у тебя строго 1:1 и новые настройки не будут добавляться.Да, я это уже понял, решил всё в одной таблице без разбивки, так явно будет проще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=32&mobile=1&tid=1540272]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
166ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
3ms |
| others: | 12ms |
| total: | 277ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
