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

7

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

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

<code>studentId varchar(12) 
date date
fn varchar(1) *forenoon*
af varchar(1) *afternoon*
</code>

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

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

Мне любопытно: почему fn и af имеют разные длины типов данных? cheduardo
@cheduardo, извините, это была опечатка Checksum
Спасибо за ответы! Как все уже отмечали, я допустил ошибку преждевременной оптимизации. Зависит от одной таблицы, а затем перейти к оптимизации, если это потребуется в будущем. Checksum
Почему ты называешь это огромным? У вас есть ограничения по пространству? Есть ли проблема с производительностью? Вы смоделировали это количество строк, чтобы получить эталонный тест? S.Lott

Ваш Ответ

5   ответов
2

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

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

Спасибо за информацию о разделении! Checksum
14

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

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

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

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

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

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

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

0

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

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

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

3

2 million records is not a big table. having a separate table per class is definitely not normalized.

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

Похожие вопросы