Designfrage - Tabellenlayout

[fkerber]

Hi!

Es geht um ein grundsätzliches Design-Problem für eine Datenbank. Ich versuche mal kurz den momentan Aufbau zu umreißen - vllt. ist dieser schon der bestmögliche, vielleicht aber auch nicht:
Es gibt in dem System Schüler und Lehrer. Für jeden gibt es momentan eine Tabelle - diese sind recht ähnlich, d.h. es gibt 10 gemeinsame Attribute und jeweils ein Attribut, das die andere "Gruppe" nicht hat.
In vielen anderen Tabellen können an gleicher Stelle Schüler oder Lehrer auftauchen, d.h. zum Beispiel der Verfasser einer Nachricht kann ein Schüler oder ein Lehrer gewesen sein. In dieser Nachrichten-Tabelle (und vielen anderen) ist es so gelöst, dass man als Verfasser z.B. "S4711" oder "L1337" drin stehen hat.
Wenn es dann darum geht den Namen des Verfassers zu ermitteln, wird über das erste Zeichen geswitched und abhängig davon entweder aus der Schüler-Tabelle gefetched oder aus der Lehrertabelle.

Die einzige Alternative, die mir jetzt einfällt wäre die folgende:
Alle "Teilnehmer" sind in einer Tabelle mit insgesamt 12 oder 13 Attributen - 12 wenn ich einfach die 10+2*1 nehme und das Vorhandensein des 11. bzw. 12. Wertes als Flag benutze - 13 wenn ich noch ein "ist-Lehrer-Flag" benutzen würde.
Dann hätte ich eine "global" eindeutige Teilnehmer-ID. Im Gegenzug dazu fange ich mir einige tausend NULL-Einträge in der Datenbank ein und die DB-Abfragen werden etwas komplizierter (dafür entfällt vorher der PHP-Aufwand).

Jetzt meine Frage:
Ist Variante 1 besser oder Variante 2?
Oder gibt es gar eine noch bessere Variante 3, die ich noch nicht sehe/kenne?

Danke und liebe Grüße,
Frederic

[Matze]

Hi Frederic,

ganz habe ich es nicht nachvollzogen, aber ich persönlich würde es wohl so lösen:

- Eine Tabelle für alle Personen
Dann hast du, wie du geschrieben hast, eine eindeutige ID und diese ist zusätzlich eine Zahl

- Die Tabelle enthält ein RechteFlag, bsp "istLehrer" vom Typ "bool".

- Extra Tabelle für die Lehrer mit den Spalten "ID" und "Feld, das die Schüler nicht haben".
Dann kannst du jeder Lehrer-ID dort die zusätzlichen Daten hinterlegen.

Das erspart dir Null-Felder und durch JOIN bekommst du deine Daten recht gut zusammen. Vielleicht geht's auch schöner. Ich würde es spontan so lösen, da es imho alles sauber getrennt ist.
Falls du das oben eh gemeint hast, ignoriere meinen Beitrag bzw. siehe ihn als Bestätigung. *g*

Grüße, Matze

[Blup]

Ich würd die Tabellen im Prinzip so aufbauen.

T_Personen <- T_Lehrer (ID_Person + Felder für Lehrer)
<- T_Schüler (ID_Person + Felder für Schüler)

Die Personen werden, abhängig von ihrer Rolle, zusätzlich mit ID in den entsprechenden Tabellen eingetragen.
In den Rollentabellen jeweils PK und FK zu T_Personen auf ID_Person.

[nahpets]

Hallo,

schau Dir mal bei Wikipedia den Artikel zur Normalisierung von Datenbanken an: http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)
Der hilft Dir da bestimmt bei den grundlegenden Überlegungen weiter.

Mein "grobes" Vorgehen ist folgendes:

Alles was an gemeinsamen Attributen vorhanden ist, in eine Tabelle, alles spezielle in entsprechende Tabellen, die nur die jeweiligen "Spezialattribute" enthalten und per Fremdschlüssel auf die gemeinsame Tabelle verweisen. Dies lässt sich beliebig in eine Baumstruktur aufteilen, da eine Spezialisierung von Spezialtabellen ebenfalls möglich ist.

Im Beispiel:

Alle Schüler und Lehrer haben gemeinsam eine Anschrift und die Kennung, von welchen Type (sprich Schüler oder Lehrer) sie sind -> eine Tabelle.
Lehrer haben von mir aus noch Attribute für Fächer und Ausbildung -> eine Tabelle für Fächer, eine Tabelle für Ausbildung.
Schüler haben eine Schulform (Grundschüler, Hauptschüler, Gesamtschüler, Realschüler, Gymnasiasten, beliebige berufsbildende Schulformen... -> eine Tabelle. Die schülerbezogenen Besonderheiten dieser Schulformen könnte man nun in weitere Tabellen aufteilen, sofern sie nicht für alle Schulformen identisch sind.

Spart das "mitschleppen" von Attributen, die nur teilweise genutzt werden und ist per SQL und Joins hervorragen, aufgabenspezifisch zu selektieren. Steckt man alles in eine Tabelle, so wird die (früher oder später) unüberschaubar breit (sprich: enthält Unmengen von Attributen, die nur jeweils in geringem Umfang genutzt werden).