Как правильно организовать структуру таблицы MySQL?

Question

[Simple91]

Доброго времени суток!

У меня сложилась немного странная ситуация. Мне нужно правильно организовать структуру бд, но я кажется иду по не верному пути.
Есть у меня таблицы: user_emp (работники), user_oper (операторы), user_clients (клиенты). То есть как вы уже догадались, это пользователи. У каждого пользователя, схожий набор данных - логин, пароль, телефон и тд.
1. Вопрос правильно ли такая структура, когда у разного типа пользователей разные таблицы? Или же, все таки стоит их просто разделить ролями, но хранить в одной таблице?
2. В MySQL есть связи между таблицами, стоит ли хранить например, телефоны юзеров в отдельной таблице "phone_numbers" и по id их связывать с главной таблицей юзеров?

Answer 1

[eudj1n]

При имеющихся вводных, оптимальной была бы структура вида:

• users - пользователи
  
• users_roles - роли пользователей
  
• roles - справочник ролей
  

Если у пользователя может быть только 1 роль - тогда можно обойтись 2 таблицами, при этом в таблице users добавить ссылку на role_id.

Если планируете хранить только телефоны - то опять же, имеет смысл писать его в основную таблицу users. Если в дальнейшем планируется расширение типов контактов и/или их множественность - то будет иметь смысл вынести все в таблицу users_contacts.

Comments

[Simple91]

Спасибо, большое. А как быть с тем, что у двоих пользователей, есть разные поля. Например: users (поле job_type : сварщик) , то есть это работник, а у юзера клиента не может быть такого поля, то что писать в это поле когда речь идет о клиенте?

[eudj1n]

Simple91: Рассмотрите так же ситуацию, когда условный сварщик может стать условным оператором :) для этих случаев есть NULLABLE-поля, заполнять которые не обязательно для всех записей.

Answer 2

[Sayonji]

1. Стоит объединить таблицы. Иначе, по-первых, возникнут проблемы с foreign key. Например, вы заходите сделать таблицу operations_history с ключом на пользователя, но не сможете, поскольку пользователи разбиты. Во-вторых, все равно потом появятся запросы по всем пользователям. Например, вам точно рано или поздно захочется найти юзера по имени, и делать это по трём таблицам будет запарно. В-третьих, потом еще появятся менеджеры, контрагенты... Будете плодить таблицы?
2. Тут вопрос только в производительности. Вынос поля в отдельную таблицу ускорит выборку, когда это поле не используется, и замедлит, когда используется. Я обычно делаю одну дополнительную таблицу, т. е. не phone_numbers, а user_meta_info, куда пишу номера телефона, года рождения и другую инфу, которая нужна только для отображения, но не фигурирует в логике системы. А имя, группу и другие данные, которые нужны почти всегда когда используется сущность user, кладу в основную таблицу.

Comments

[Simple91]

Очень интересен ваш подход во втором вопросе. Я тоже задумывал что-то подобное, чтобы эти данные просто были, а логику разделить. А можно чуть подробнее на счет этого подхода, то есть нужна отдельная таблица: "users_info" c полями, "user_id", "user_fio", "user_like_color" ?

[Sayonji]

Да. Я, правда, обычно оставляю user_fio в основной таблице, поскольку это поле нужно часто (почти во всех местах, где нужен юзер, выводится его имя). Можете еще создать view, являющийся джойном главной таблицы с дополнительной. И вы сможете просто использовать таблицу users или вьюшку users_extended в зависимости от того, что вам нужно. Но это уже по желанию.

Answer 3

[Евгений Вольф]

все таки стоит их просто разделить ролями, но хранить в одной таблице?

Иначе говоря, не денормализовывайте данные (не дробите их).

В MySQL есть связи между таблицами, стоит ли хранить например, телефоны юзеров в отдельной таблице "phone_numbers" и по id их связывать с главной таблицей юзеров?

Стоит, если у Вас действительно большой объём данных, сервер не справляется а телефони пр. параметры - запрашиваются относительно редко по сравнинию кол-вом запросов в таблицу пользователей. В этом случае, все редко используемые данные выносят в отдельную таблицу, что бы физически разделить их на диске и уменьшить объём основной таблице. При этом, данные из доп. таблицы получают отдельным запросом (без JOIN'ов). А вообще, когда такое случается (когда данных уже столько, что массив дисковый массив захлёбывается и данные приходятся дробить, индексы перестают работать нормально а внешние ключи сыпятся) - уже пора переходить на Postgresql, а не мучить MySQL, которая тихи и мирно начинает скатываться в "черную дыру непонятных ошибок"...

Comments

[eudj1n]

Не холливара ради - расскажите на каких объемах начинает "сыпаться" MySQL?

[Евгений Вольф]

eudj1n: на нескольких терабайтах данных уже начинали наблюдаться подобные артефакты. Точный объём данных подсказать не могу, там (сис.) админы над базой чахли как Кощей над златом, близко не подпускали...