Рекомендации по проектированию БД: возвращать несколько строк с отдельными записями или одну строку с несколькими записями?

0

Я ищу, чтобы собрать матрицу как для навыков, так и для образования. У меня будут столбцы:

skills_mat_id | user_id | skill | competency_level | priority_level |

и что-то похожее для образования, где competency_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/пустых полей), но второй вариант кажется более "эффективным" и возвратит одну строку для того, что может быть большой список навыков. Имеет ли какой-либо вариант разницу в производительности? Является ли это скорее проблемой front-end? Или дизайнерское решение окажет существенное влияние на производительность БД. Я буду использовать MySQL для этого, но я не особенно отчасти привязан к какой-либо одной платформе базы данных.

Я немного обеспокоен чем-то вроде обновления или удаления определенного навыка со вторым вариантом. Я не был бы слишком уверен в том, как это сделать так, чтобы уменьшить вероятность случайного удаления или обновления неправильной части записи.

Мы рассматриваем потенциально сотни тысяч пользователей, которые существенно расширили бы таблицы "навыки" или "образование", и поэтому было интересно, существует ли подход к набору данных, подобный этому, с точки зрения передовой практики?

Теги:
sql-server

2 ответа

2
Лучший ответ

Оптимизация для однострочных чтений по сравнению с несколькими рядами очень глубоко на территории преждевременной микрооптимизации. Если вы индексируете таблицу с помощью skill_mat_id + user_id, выбор этих столбцов должен быть очень быстрым. Производительность также не должна быть проблемой. С другой стороны, если вы храните его в формате запятой, его трудно поддерживать, подвергать ошибкам, а интерфейсный интерфейс в любом случае должен выполнять работу по слиянию каждого имени навыка с навыками. Всегда делайте это сначала, дизайн для модульности и элегантности, а затем оптимизируйте производительность только в случае необходимости.

Если вам абсолютно нужна эта производительность, то сравните ее и посмотрите, стоит ли дополнительное повышение. Скорее всего, это не так, по большому счету.

0

Несколько строк лучше с точки зрения простоты.

В противном случае вам нужно будет совершить цикл вокруг каждого поля.

Плюс, что вы сохраняете? Немного. Если вы поместите несколько строк, вы получите приличную экономию места. Если вы добавите несколько сотен, вы получите лучшее сжатие от zip-утилиты.

Код для простоты, поэтому его легче отлаживать.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню