ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Стоит ли разбивать таблицу на две?
19 сообщений из 19, страница 1 из 1
Стоит ли разбивать таблицу на две?
    #39326719
Gamletus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gamletus
Гость
Всем привет. Требуется ответ специалистов.
В данный момент имеется таблица users, в которой содержаться поля с логином, именем, фамилией, почтой, полом и прочая стандартная инфа. Также имеются множество полей с различными настройками для юзеров, таких полей с настройками планируется примерно 20-30, может и больше. Хранимые значения там будут совсем короткие, не более 10 символов в каждом. Обновлять настройки как мне кажется пользователи будут не часто.
Вот появилась мысль личные данные пользователей оставить в таблице users, а вот настройки пользователей вынести в таблицу settings, быть может ещё и связать их внешним ключом по id
Уважаемые специалисты, подскажите, стоит ли выносить настройки в отдельную таблицу и нужно ли их связывать внешним ключом?
С внешними ключами вообще никогда не работал, но погуглив понял, что в данном случае их было бы полезно применить.
...
Рейтинг: 0 / 0
14.10.2016, 05:40
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39326720
Gamletus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gamletus
Гость
Забыл добавить, если это важно конечно. Таблицы InnoDB
...
Рейтинг: 0 / 0
14.10.2016, 05:44
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39326815
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Злой Бобр
Участник
Gamletus... стоит ли выносить настройки в отдельную таблицу и нужно ли их связывать внешним ключом?
Если вы не знаете количество настроек (или в ближайшем будущем оно изменится) - выносите. Да, стоит (у вас стандартный EAV - гуглите и читайте).
...
Рейтинг: 0 / 0
14.10.2016, 09:59
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39327230
Gamletus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gamletus
Гость
Я ещё хотел уточнить, т.к. пока гуглил, нашёл ситуацию чем-то похожую, но там выносили в отдельную таблицу, когда для одного пользователя создавалось несколько строк с данными (именно строк). У меня же как в таблице users, так и в таблице settings будет строго по одной строке для каждого пользователя. А вот количество столбцов в settings будет примерно 20-30...
...
Рейтинг: 0 / 0
14.10.2016, 16:10
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39327249
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
GamletusУ меня же как в таблице users, так и в таблице settings будет строго по одной строке для
каждого пользователя. А вот количество столбцов в settings будет примерно 20-30...

Это плохой дизайн. Заверни все настройки в JSON и храни в одном поле таблицы users.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
14.10.2016, 16:25
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39327312
Gamletus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gamletus
Гость
Dimitry SibiryakovЭто плохой дизайн. Заверни все настройки в JSON и храни в одном поле таблицы users.Идея хорошая, но мне кажется будет сложновато при добавлении каких-то новых настроек так, чтобы они добавились сразу у всех пользователей без лишних заморочек. Когда каждая настройка хранится в отдельном столбце, то вроде как добавил новый столбец и всё.
...
Рейтинг: 0 / 0
14.10.2016, 18:05
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39327336
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Gamletusно мне кажется будет сложновато при добавлении каких-то новых настроек так, чтобы они
добавились сразу у всех пользователей без лишних заморочек.

А зачем их добавлять всем пользователям сразу? Если какой-то настройки в БД нет -
используй умолчательное значение для неё. Не вижу никакой проблемы с этим.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
14.10.2016, 18:55
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39327348
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Gamletusвот количество столбцов в settings будет примерно 20-30...
хм... а я бы сделал всего четыре колонки: id, settingKey, settingValue и userId
...
Рейтинг: 0 / 0
14.10.2016, 19:17
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39327400
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vmag
Участник
GamletusИдея хорошая, но мне кажется будет сложновато при добавлении каких-то новых настроек так, чтобы они добавились сразу у всех пользователей без лишних заморочек. Когда каждая настройка хранится в отдельном столбце, то вроде как добавил новый столбец и всё.

новый столбец в таблице это не всё, это только начало, за этим обычно идет изменение интерфейса, средств выборки и т.д.
...
Рейтинг: 0 / 0
14.10.2016, 21:51
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39327503
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
GamletusВот появилась мысль личные данные пользователей оставить в таблице users, а вот настройки пользователей вынести в таблицу settings, быть может ещё и связать их внешним ключом по id
Уважаемые специалисты, подскажите, стоит ли выносить настройки в отдельную таблицу и нужно ли их связывать внешним ключом?Если это настройки "для всех", если нет разделения пользователей на некие типы, если это не "пользовательские" настройки, которые сами пользователи могут добавлять когда захотят, то зачем вообще такие сложности, зачем такой дизайн с EAV?

В СУБД уже есть средства управления полями таблиц, связями, констрейнами, индексация, и.т.д, зачем создавать дополнительные, свои, разве есть надежда сделать их лучше, чем то, что уже имеется в СУБД?

Используйте просто обычные поля в таблице.

Вопрос - выносить ли это в отдельную таблицу. Если это некая отдельная сущность, которая будет использоваться независимо, ну, тогда можно выделить в отдельную таблицу.

Связывать 1=1 с юзерами - зависит от того, может ли "настройка пользователя" управляться отдельно от пользователя (например, будет настройка "оператор", и все пользователи операторы работают с этой настройкой).
...
Рейтинг: 0 / 0
15.10.2016, 12:14
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39327771
Фотография S.G.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
S.G.
Участник
skyANAGamletusвот количество столбцов в settings будет примерно 20-30...
хм... а я бы сделал всего четыре колонки: id, settingKey, settingValue и userId+1
...
Рейтинг: 0 / 0
16.10.2016, 13:55
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39327813
Gamletus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gamletus
Гость
Два дня тестировал все предложенные варианты и всё-таки решил не выносить в отдельную таблицу, решил делать каждый тип настроек в отдельном столбце. Но однозначно решил делать кеш в виде файла для каждого пользователя, завернув пхпшной функцией json_encode/json_decode, чтобы понапрасну в базу не обращался. Как-то так ))
...
Рейтинг: 0 / 0
16.10.2016, 17:21
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39327962
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
Dimitry SibiryakovGamletusУ меня же как в таблице users, так и в таблице settings будет строго по одной строке для
каждого пользователя. А вот количество столбцов в settings будет примерно 20-30...

Это плохой дизайн . Заверни все настройки в JSON и храни в одном поле таблицы users.
Поэтому предлагаешь еще более плохой ???
Справочник пользователей никогда не бывает очень большим, поэтому 20-30 полей-настроек никак не повлияет на производительность.

Как вариант - прикрутить что-то вроде EAV. Пригодиццо не только для пользователей.
...
Рейтинг: 0 / 0
17.10.2016, 09:10
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39327971
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
Если настроек будет до 30, и есть надежда, что их количество со временем устаканится, то вполне допустимо будет добавить 30 полей в таблицу users и не мучиться. Выделять отдельную таблицу со связью 1:1 никакого смысла нет.

Если же предполагается, что регулярное выдумывание и добавление новых настроек для пользователей - нормальное явление в жизни БД - тогда да, можно EAV.
...
Рейтинг: 0 / 0
17.10.2016, 09:24
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39328163
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дедушка
Участник
Dimitry SibiryakovЭто плохой дизайн. Заверни все настройки в JSON и храни в одном поле таблицы users.нормальные формы теперь не модны?
...
Рейтинг: 0 / 0
17.10.2016, 13:36
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39328183
Gamletus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gamletus
Гость
Cane Cat FisherЕсли же предполагается, что регулярное выдумывание и добавление новых настроек для пользователей - нормальное явление в жизни БД - тогда да, можно EAV.Количество настроек однозначно устаканится ))
...
Рейтинг: 0 / 0
17.10.2016, 13:54
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39328521
Serguei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Serguei
Участник
Чтобы понять стоит ли разносить данные по разным таблицам я смотрю как часто меняются данные и их зависимость друг от друга.
У меня, например, логины-пароли вынесены в отдельную таблицу- это явно независящие от остальных настроек данные, а настройки системы хранятся в EAV- очень легко добавлять новые настройки.
...
Рейтинг: 0 / 0
17.10.2016, 20:06
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39328648
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
GamletusДва дня тестировал все предложенные варианты и всё-таки решил не выносить в отдельную таблицу, решил делать каждый тип настроек в отдельном столбце. Но однозначно решил делать кеш в виде файла для каждого пользователя, завернув пхпшной функцией json_encode/json_decode, чтобы понапрасну в базу не обращался. Как-то так ))


ты очень много думаешь.
сделай хоть как-то.

на самом деле нет смысла делить на две таблицы если у тебя строго 1:1 и новые настройки не будут добавляться.
...
Рейтинг: 0 / 0
18.10.2016, 07:39
| Ответить | Цитировать | Написать  
Стоит ли разбивать таблицу на две?
    #39328933
Gamletus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gamletus
Гость
MasterZivты очень много думаешь.Потому, что если заранее много не подумать, то потом приходится много переделывать )) да и время позволяет никуда не спешить.

MasterZivсделай хоть как-то.Хоть как-то - это точно не для меня.

MasterZivна самом деле нет смысла делить на две таблицы если у тебя строго 1:1 и новые настройки не будут добавляться.Да, я это уже понял, решил всё в одной таблице без разбивки, так явно будет проще.
...
Рейтинг: 0 / 0
18.10.2016, 13:22
| Ответить | Цитировать | Написать  
19 сообщений из 19, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Стоит ли разбивать таблицу на две?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&fpage=13&tid=1540272]:
 0ms
get settings:
 9ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 41ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 57ms
get tp. blocked users:
 2ms
others: 13ms
total:  158ms
созд. / загр.: 158ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]