MYSQL — Где размещать дополнительные поля?

Question

[Максим]

Всем привет!

Не как не могу разобраться с терзающими меня вопросами. Раньше не задумывался о таких вещах. Возможно, и вам вопрос покажется банальным. Однако прошу помочь!

Суть следующая... В проекте есть не так много таблиц, в которых указывается основная информация. Например, таблица user и в ней поля: last name, name, phone.... Это основные поля Таблицы. Помимо их есть вспомогательные поля, чаще всего счетчики: кол-во просмотров, кол-во рейтинга, последнее посещение (unixtime)

Сейчас поля типа: views_count, rating_count, находятся прямо в таблице, которой они нужны. В данном случае user. И у меня появились сомнения по правильности их размещения. Вполне возможно, что их необходимо выделить в отдельную таблицу: user_counter. Особенно, если счетчиков пользователя будет гораздо больше, что вполне возможно.

Подскажите, на сколько это правильно? На сколько это целесообразно? И вообще по какому принципу выделять поля в отдельные таблицы или в отдельные вспомогательные таблицы?

Хочется до конца прояснить эти вопросы и разобраться в них. На просторах интернета ничего толкового не нашёл. Если я что-то пропустил буду раз ссылкам!

Благодарю!

Answer 1

[Roman Sokolov]

Приведи таблицу в 3НФ и тогда понятно станет, что лишнее, а что нет.

Comments

[Максим]

Не до конца разбираюсь в нормализациях. Можете пояснить на моем примере.

Answer 2

[Иван Шумов]

В разных случаях решение может быть разным, но в общем случае при денормаоизацию есть простое правило - в одной таблице хранятся только свойства объекта. У вас есть пользователь. Число просмотров является его свойством для вашей системы?

Comments

[Максим]

Да, число просмотров относится к пользователю. По этому полю бывает сортировка. Правильно ли я понимаю, что его нужно оставить в user?

[Иван Шумов]

Максим, если в вашей системе так то пожалуйста. Но я бы не согласился. Вот смотрите - ваша рука является вашей частью? Да. А является ли вашей частью число ваших друзей?

[Максим]

Иван Шумов, согласен. Тогда куда нужно определять такие поля? И если такое роле всего одно?

[Иван Шумов]

Максим, есть миллионы вариантов. Решать вам)

[Максим]

Иван Шумов, понял. Тут просто сразу идёт дополнительный запрос join. Поэтому, скорее всего пока правильней оставить в общей таблице. Но если будет количество счетчиков расти, то можно вынести

[Иван Шумов]

Максим, главное помните о безопасности. Скрипт, обновляющий счётчик не должен иметь шанс случайно повлиять на запись пользователя. Неожиданным образом.

[Максим]

Иван Шумов, да. Это понятно) Спасибо

Answer 3

[Константин Цветков]

Два крайних варианта:

• все дополнительные атрибуты хранить в основной таблице;
  
• атрибуты хранить в таблицах тип_атрибута, атрибут,значение_атрибута для объекта.
  

Дополнительная таблица посредине.

Answer 4

[Vitsliputsli]

Подскажите, на сколько это правильно? На сколько это целесообразно?

А что именно сейчас смущает в существующей структуре? Исходите из того, что реально может помочь, а не то, что "правильно". Разбиение на несколько таблиц это затраты на join. Нет идеальных решений, любая оптимизация это жертвование чем-то, ради чего-то еще. Никто лучше вас не знает вашу систему, что произойдет после преобразований? Насколько усложнятся или упростятся запросы к БД, как по производительности, так и по читаемости?
Как вы хотите представить эти данные в новой таблице? Attribute-Entity-Value? Если да, то прикиньте насколько усложнится система и отяжелеют запросы. "Счетчиков будет гораздо больше 2," это сколько? 10-20? Тогда даже не стоит заморачиваться, если больше 100, тогда, да, можно уже сейчас начать изменять струкутуру.

Comments

[Максим]

Благодарю) Хорошее пояснение!)