Задать вопрос
myks92
@myks92
Нашёл решение — пометь вопрос ответом!
mysql

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

Всем привет!

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

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

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

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

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

Благодарю!
  • Вопрос задан
  • 131 просмотр
Комментировать
Подписаться 1 Простой Комментировать
Решения вопроса 4
@jimquery
Приведи таблицу в 3НФ и тогда понятно станет, что лишнее, а что нет.
Ответ написан
1 комментарий
1 комментарий
inoise
@inoise
Solution Architect, AWS Certified, Serverless
В разных случаях решение может быть разным, но в общем случае при денормаоизацию есть простое правило - в одной таблице хранятся только свойства объекта. У вас есть пользователь. Число просмотров является его свойством для вашей системы?
Ответ написан
7 комментариев
7 комментариев
tsklab
@tsklab
Здесь отвечаю на вопросы.
Два крайних варианта:
  • все дополнительные атрибуты хранить в основной таблице;
  • атрибуты хранить в таблицах тип_атрибута, атрибут,значение_атрибута для объекта.

Дополнительная таблица посредине.
Ответ написан
Комментировать
Комментировать
@Vitsliputsli
Подскажите, на сколько это правильно? На сколько это целесообразно?

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
Вакансии с Хабр Карьеры
Программист C++ Builder / базы данных MySQL
RU Electronics • Москва
от 180 000 до 200 000 ₽
Инженер технической поддержки с английским языком и знанием PHP/MySQL
IT-Aces
от 100 000 до 150 000 ₽
Системный аналитик
ROBOTMIA • Новосибирск
от 100 000 ₽
Ещё вакансии
Заказы с Хабр Фриланса
Расработка Парсер для сайта https://soliq.uz/activities/debtor
19 апр. 2024, в 19:51
3000 руб./за проект
Два скрипта, Python, web3.py, вызов функции смарт-конракта
19 апр. 2024, в 19:47
50000 руб./за проект
Сделать дизайн главной страницы сайта
19 апр. 2024, в 19:17
1500 руб./за проект
Ещё заказы