Я хочу составить матрицу для деталей как навыков, так и образования. У меня будут столбцы:
skills_mat_id | user_id | skill | competency_level | priority_level |
И что-то подобное для образования, где comptency_level и priority_level могут быть пустыми в форуме (или NULL в БД).
Вопрос в том, должен ли я создавать отдельную строку для каждого навыка, то есть:
1, user1, java, 7, 1
2, user1, php, 6, 2
3, user1, css, 4, 2
4, user1, python, 8, NULL
Или все должно быть в одном столбце:
1|user1|java,php,css,python|7,6,4,8|1,2,2,NULL
Мне кажется, что первый вариант намного проще реализовать (и менее подвержен ошибкам с интерфейсом из-за NULL / пустых полей), но второй вариант кажется более «эффективным» и вернет одну строку для того, что может быть большой список навыков. Любой из вариантов влияет на производительность? Это больше проблема внешнего интерфейса? Или проектное решение существенно повлияет на производительность БД. Я буду использовать для этого MySQL, но я не особо привязан к какой-либо платформе баз данных.
Меня немного беспокоит что-то вроде обновления или удаления определенного навыка с помощью второго варианта. Я не был бы слишком уверен в том, как это сделать так, чтобы уменьшить вероятность случайного удаления или обновления неправильной части записи.
Мы смотрим на потенциально сотни тысяч пользователей, которые могли бы существенно расширить таблицы «навыки» или «образование», и поэтому задавались вопросом, есть ли лучший практический подход к такому набору данных?
2 ответа
Оптимизация для чтения одной строки по сравнению с несколькими строками очень глубоко находится на территории преждевременной микрооптимизации. Если вы индексируете таблицу с помощью skill_mat_id
+ user_id
, выбор по этим столбцам должен выполняться очень быстро. Производительность даже не должна вызывать беспокойства. С другой стороны, если вы сохраните его в формате запятой, его будет сложно поддерживать, он подвержен ошибкам, и интерфейс в любом случае должен будет выполнять работу по объединению каждого имени навыка с уровнем владения. Всегда заставляйте его работать сначала, создавайте модульность и элегантность, а затем оптимизируйте производительность только при необходимости.
Если вам абсолютно необходима такая производительность, протестируйте ее и посмотрите, стоит ли этого дополнительного повышения. По большому счету, скорее всего, нет.
Несколько строк лучше с точки зрения простоты.
В противном случае вам нужно будет зацикливаться рядом с каждым полем.
Плюс, что вы экономите? Немного. Если поставить несколько рядов, получится приличная экономия места. Если вы добавите несколько сотен, вы получите лучшее сжатие с помощью утилиты zip.
Код для простоты, поэтому его легче отлаживать.
Новые вопросы
mysql
MySQL - это бесплатная система управления реляционными базами данных с открытым исходным кодом (RDBMS), использующая язык структурированных запросов (SQL). НЕ ИСПОЛЬЗУЙТЕ этот тег для других БД, таких как SQL Server, SQLite и т. Д. Это разные БД, которые все используют свои собственные диалекты SQL для управления данными.