Нужно ли выносить не очень важные данные в отдельную таблицу MySQL
Имеем такую ситуацию, есть основная сущность со своими основными данными и есть еще дополнительные данные о ней которые нужно хранить, но отображаться будут они при определенной логике не очень часто. В поиске не участвуют, просто текст который надо показать в определенный момент.
Стоит ли такого плана данные помещать в основую таблицу сущности, или может быть стоить создать таблицу типа entity_metadata и там поля entity_id, name и value где и будут лежать эти не оч важные данные основной сущности в ключ-значение ?
Но тут сразу возникает вопрос, если будет по 5 записей метаданных к каждой основной в итоге получим таблицу в который будет в 5 раз больше записей, не скажется ли это на производительности mysql сервера? Какой вариант лучше и правильнее?
Ответы (3 шт):
Наверное стоит следовать нормальным формам таблиц :-) С точки зрения НФ - именно так и следует сделать, с точки зрения производительности - Вы же сами написали, что данные будут отображаться не так уж часто.
Имеет смысл создать таблицу ключ-значение, как вы описали, только если ключ может быть динамическим или есть разные "типы" с отдельными набором свойств (хотя и тут можно иначе обыграть), или если есть 100% уверенность, что поиска по ним не будет и их ну очень уж много.
Для 5-ти свойств создавать отдельную таблицу, скорее всего смысла не имеет.
Я бы сделал так:
- меньше 20 свойств- в одну таблицу.
- 20-40 полей - две таблицы со связью "один к одному".
- больше 40 - думать, возможно что-то не так с изначальным дизайном. Возможен вариант "ключ-значение".
Вот кстати инфа по влиянию количества колонок (и их типа) на скорость, разница между 1 колонкой и 100 ~ 70%. https://www.percona.com/blog/2009/09/28/how-number-of-columns-affects-performance/
Все зависит от ситуации, исходя из своего опыта говорю,что не встречал не одной промышленной базы данных построенной по третьей нормальной форме. Задачу оптимизации нужно решать по мере поступления задач, потому что это очень дорого и оптимальное решение как правило плохо расширяется. В данной ситуации вам не стоит беспокоится на этапе проектирования, потому что разделить таблицу всегда можно. У меня встречались таблицы 600+ колонок в которой активно использовались только 20 полей и для этого они дублировались в другой таблице, да избыточность есть но сейчас вопрос с памятью не на столько острая как 10 лет назад.