База данных слишком велика - хранить как строку или сериализовать данные?

Question

У меня есть приложение для викторины, которое состоит из множества модулей, содержащих вопросы.Каждый вопрос имеет много категорий (многие ко многим).Каждый раз, когда тест завершается, оценка пользователя отправляется в таблицу результатов.(Я приложил диаграмму отношения сущностей для пояснения).

Я думал о том, чтобы разбить пользовательские оценки по категориям (то есть пользователь при завершении теста получит общую оценку теста вместе сбалл за каждую категорию).

Однако, если каждый тест состоит не менее чем из 30 вопросов, в каждом тесте может быть около 15-20 категорий.Таким образом, если один пользователь завершит тест, он создаст минимум 15-20 строк в таблице результатов.Для нескольких пользователей таблица баллов очень быстро станет очень большой.

Я предполагаю, что это повлияет на производительность извлечения данных из таблицы баллов.Например, если я хотел вычислить средний балл для пользователя для определенной категории.

Есть ли у кого-нибудь лучшее предложение о том, как я все еще могу хранить результаты, основанные на категориях?

Я думал о сериализации данных JSON, но, конечно, у этого есть свои ограничения.

Answer 1

БД должна уметь обрабатывать миллионы строк, и в вашем дизайне нет ничего плохого.Несколько вещей, которые я бы посоветовал:

• Поместить индексы в следующий (или комбинацию) идентификатор пользователя, идентификатор экзамена (который, как я полагаю, является тем, что вы называете scurable id) тип экзамена (scorable Type?) и дата создания.

• По мере роста вашей таблицы делите ее на части.Потенциальными кандидатами могут быть корзины с датами создания (по годам или годам / месяцам, вероятно, будет работать хорошо) или, возможно, если учащиеся посещают определенные классы, у вас могут быть группы классов

• Поскольку ваша таблица растет еще большеВы можете переместить разделы на разные диски (то, как вы разбили данные на разделы, будет еще более важным здесь, потому что, если данные должны проходить через слишком много разделов, вы можете в конечном итоге ухудшить производительность, а не помогать)

Помимо этого, другим предложением было бы разбить таблицу оценок на две оценки и ScoreDetail.Таблица результатов будет содержать данные верхнего уровня, такие как идентификатор пользователя, идентификатор экзамена, общий балл и т. Д. В то время как дочерняя таблица будет содержать оценки по категориям (философия и т. Д.).Я бы поспорил, 80% времени люди все равно заботятся только о высшем балле.Таким образом, вы можете обратиться к большему столу только тогда, когда кто-то хочет узнать подробности своего счета на конкретном экзамене.

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

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

Answer 2

Я сомневаюсь, что сериализация даст вам существенную выгоду Я бы даже осмелился сказать, что вы как бы ограничиваете возможности базы данных, делая это.

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

Кроме того, вам нужно будет десериализовать каждый раз, когда вы хотите читать из таблицы. Это исключило бы возможность использовать операторы SQL для сортировки, фильтрации, объединения и т. Д.

Таким образом, в конечном итоге вы, вероятно, создадите себе больше проблем, сериализовав, чем просто сохраняя строки.