Datenbankentwurf für Schulbesuchssystem

Question

Ich arbeite an einem Projekt für eine Schule, wo ein bestimmtes Modul mit Anwesenheitssystem beschäftigt. Ich verwende LAMP (PHP 5.2+ MYSQL 5+) Stack für die Entwicklung. Jetzt liegt die Schulstärke bei etwa 1500 und die Gesamtzahl der Arbeitstage pro Jahr beträgt etwa 250. Außerdem muss ich Aufzeichnungen für 5 Jahre aufbewahren, bevor sie gelöscht werden können.

Die Tabellenstruktur ist

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

Wenn ich einfach eine einzelne Tabelle verwenden, die 1.875.000 Datensätze für einen Zeitraum von 5 Jahren bedeutet. Anstatt eine so riesige Datenbank zu erstellen, überlegte ich, eine Tabelle für jede Klasse zu erstellen (keine Sektion). Wenn man bedenkt, dass es 12 Klassen gibt, habe ich 12 Tabellen, was einem Durchschnitt von 1,55.000 Datensätzen pro Tabelle entspricht, was überschaubar ist.

Ist dies der richtige Weg? Oder gibt es bessere Wege?

Answer 1

Was Sie tun, ist eine vorzeitige Optimierung genannt. Dies ist ein häufiger Fehler.

Sie sind besser Ihre Datenbankstruktur, wie nah an der Realität und in Zukunft immer wenn es einen Bedarf für die Optimierung oder Verbesserung der Geschwindigkeit wird man immer das tun kann.

Aus Erfahrung und mit Blick auf Ihr Beispiel sieht die Single-Table-Lösung gut aus.

Answer 2

Solange Sie Ihre Tabellenspalten richtig indiziert haben, sollte es kein großes Problem mit der ersten Tabelle geben.

Ich würde nicht mit der Idee übereinstimmen, es in die 12 Klassen aufzuteilen, weil Sie keine Garantie dafür haben, dass es so bleibt (Klassen hinzugefügt, Klassen zusammenführen, etc.).

Mucking Datenbank Normalisierung für eine wahrgenommene Nutzen der Effizienz bis etwas, das Sie nur für extreme Umstände aussehen sollte (wenn überhaupt)

Answer 3

Ein paar Punkte.

2 Millionen Datensätze ist nicht eine große Tabelle.

mit einer separaten Tabelle pro Klasse ist definitiv nicht normalisiert.

Sie haben nicht wirklich genügend Informationen über Links zu anderen Tabellen und was sonst noch, wenn diese Tabelle speichert. Aber Sie sollten mit 3NF für alle Tabellen beginnen und nur das ändern, wenn Sie Leistungsprobleme finden.

Answer 4

Ich würde vorschlagen, dass diese Tabelle nicht aufgeteilt werden muss. Wenn Sie geeignete Indizes für selektive Abfragen erstellen, die Sie möglicherweise ausführen müssen, sollte das System in der Lage sein, die erforderlichen Zeilen sehr schnell zu finden. Selbst bei analytischen Abfragen, die alle Zeilen betreffen, sollten 2 Millionen solcher Datensätze nur ein oder zwei Sekunden zum Scannen benötigen, was meines Erachtens kein großes Problem darstellen würde.

MySQL unterstützt jetzt auch die Partitionierung von Daten als optionale Funktion. Die Partitionierung ähnelt Ihrem Vorschlag, die Tabelle aufzuteilen, dies geschieht jedoch auf der physischen Ebene, sodass sie für Benutzer oder Entwickler, die Ihr Schema verwenden, nicht sichtbar ist. Dies kann nützlich sein, wenn Sie feststellen, dass eine Implementierung mit einer einzelnen Tabelle immer noch zu langsam ist. This document bietet einen Überblick über die Partitionierung in MySQL 5.4.

Answer 5

Checksum,

I echo Michiel opinin, dass diese vorzeitige Optimierung ist.

Im Grunde können Sie später die Leistung verbessern, indem Sie die Datenbankarchivierungs- und Partitionierungsfunktionen verwenden, damit Ihre Datenbanklesevorgänge effizient sind. Ich kann auch Index für diese Tabelle erstellen. Jedenfalls glaube ich nicht, dass 1 Million Datensätze riesig sind. Datenbanken sind heute in der Lage, solche großen Zahlen zu verarbeiten. Auch werden Sie die Leistungsprobleme 3 Jahre Formular jetzt nur

begegnen Also gehen Sie weiter schreiben Sie lieber Code als darüber nachzudenken, was schief geht!