Разработка базы данных для системы посещаемости школы

Question

Я работаю над проектом для школы, где конкретный модуль имеет дело с системой посещаемости. Я использую LAMP (PHP 5.2+ MYSQL 5+) для разработки. Сейчас численность школы составляет около 1500, а общее количество рабочих дней в году - около 250. Кроме того, я должен вести записи в течение 5 лет, прежде чем их можно будет стереть.

Структура таблицы

studentId varchar(12) 
date date
fn varchar(1) *forenoon*
af varchar(1) *afternoon*

Если я просто использую одну таблицу, это означает 1 875 000 записей за 5-летний период. Теперь вместо такой огромной базы данных я подумал о создании таблицы для каждого класса (а не раздела). Таким образом, учитывая, что существует 12 классов, у меня будет 12 таблиц, что означает в среднем 1,55 000 записей на таблицу, которыми можно управлять.

Это правильный способ сделать это? Или есть способы получше?

Answer 1

То, что вы делаете, называется преждевременной оптимизацией. Это распространенная ошибка.

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

Судя по вашему примеру, решение для одного стола выглядит прекрасно.

Answer 2

Пара баллов.

• 2 миллиона записей - это не большая таблица.
• наличие отдельной таблицы для каждого класса определенно не нормализовано.

Вы не предоставили достаточно информации о ссылках на другую таблицу и что еще, если что-нибудь, эта таблица будет хранить. Но вы должны начинать с 3NF для всех таблиц и изменять его только в случае проблем с производительностью.

Answer 3

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

MySQL теперь также поддерживает разделение данных в качестве дополнительной функции. Разделение похоже на ваше предложение разбить таблицу на части, но это делается на физическом уровне, поэтому она не видна пользователям или разработчикам, использующим вашу схему. Это может быть полезным подходом, если вы обнаружите, что реализация одной таблицы все еще слишком медленная. В этом документе представлен обзор секционирования в MySQL 5.4.

Answer 4

Если вы правильно проиндексировали столбцы таблицы, с первой таблицей проблем быть не должно.

Я бы не согласился с идеей разбить его на 12 классов, потому что у вас нет гарантии, что так оно и будет (добавленные классы, слияние классов и т. Д.).

Отслеживание нормализации базы данных для ощутимого преимущества в эффективности - это то, на что вы должны смотреть только при экстремальных обстоятельствах (если вообще когда-либо)

Answer 5

Контрольная сумма

Я повторяю мнение Михеля о том, что это преждевременная оптимизация.

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

Так что пишите код, а не думайте о том, что не так!