Frage zu mysql-Struktur

[Rick]

Hallo,

ich hab mal ne Frage zur Struktur einer mysql-Datenbank.

Wenn ich eine Tabelle: "User" habe, was entscheidet dann darüber, ob ich ein Profilfeld in selbige "usertable" hineinschreibe oder dafür eine weitere Tabelle erstelle, die in Relation zur "usertable" steht?
------------------------------------------------------
Beispiel:

Ich habe einmal die Tabelle "user" und einmal die Tabelle "abteilung". Ganz klar, daß ich über den Primärschlüssel User_ID die Relation herstelle.

Aber könnte/müsste ich das nicht im Extrem bis ins kleinste Detail so machen?

Tabelle Geschlecht: männlich/weiblich, Primärschlüssel= User_ID
Tabelle Name: Textfeld, Primärschlüssel= User_ID
Tabelle Vorname; Textfeld, Primärschlüssel= User_ID
-------------------------------------------------------------

Letztlich frage ich mich dann, was steht überhaupt noch in der Tabelle "user" drin, außer der ID ????

Also wann geht man über die Relation von Tabellen und wann schreibts mans einfach in die Haupttabelle "user"??

Denn mit den paar Tabellenfeldern würde ja auch eine einzige Tabelle ausreichen...??

Grüße, Rick

[wahsaga]

hi,

Ich habe einmal die Tabelle "user" und einmal die Tabelle "abteilung". Ganz klar, daß ich über den Primärschlüssel User_ID die Relation herstelle.

Aber könnte/müsste ich das nicht im Extrem bis ins kleinste Detail so machen?

Generell dreht sich deine Frage also um Normalisierung - dazu lies ruhig mal bei der Wikipedia nach,
http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)

Da findest du u.a. erklärt, dass man im allgemeinen fünf solcher Normalformen unterscheidet (Boyce-Codd als zusätzliche) - aber das in der Praxis idR. nicht "bis zum Ende" durchzieht, weil das weniger sinnvoll wäre.

Tabelle Geschlecht: männlich/weiblich, Primärschlüssel= User_ID
Tabelle Name: Textfeld, Primärschlüssel= User_ID
Tabelle Vorname; Textfeld, Primärschlüssel= User_ID

Letztlich frage ich mich dann, was steht überhaupt noch in der Tabelle "user" drin, außer der ID ????

Die letzten beiden solltest du auf jeden Fall in der User-Tabelle mit drin haben.
Und die erste auch - nur nicht unbedingt den Text "männlich" oder "weiblich", sondern eher ein Kennzeichen wie "m" und "w" oder 0 und 1 oder "m" und "f" (nach den englischen Geschlechtsbezeichnungen).

gruß,
wahsaga

[Rick]

Hi Wahsaga,

danke für den Link und Deine Antwort.
ich werds mir gleich mal anschauen. Wird aber sicher so ähnlich sein, wie das mir vorliegende Buch "SQL-Der Schlüssel zu relationalen Datenbanken", welches ausgesprochen gut geschrieben ist, mir aber gerade im Teil "Normalisierung" etwas zu kompliziert geschrieben war *schäm*

Deshalb finde ich dann oft ein paar Antworten von Menschen, "wie Du und ich" angenehm...

Dank Dir und Grüße

Rick

[_King Lully]

Generell dreht sich deine Frage also um Normalisierung - dazu lies ruhig mal bei der Wikipedia nach,
http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)

Erst einmal geht es um das ERM:
http://de.wikipedia.org/wiki/Entity_Relationship_Model

[romy]

Hi Rick,

Beispiel:
Ich habe einmal die Tabelle "user" und einmal die Tabelle "abteilung". Ganz klar, daß ich über den Primärschlüssel User_ID die Relation herstelle.

Aber könnte/müsste ich das nicht im Extrem bis ins kleinste Detail so machen?
Tabelle Geschlecht: männlich/weiblich, Primärschlüssel= User_ID
Tabelle Name: Textfeld, Primärschlüssel= User_ID
Tabelle Vorname; Textfeld, Primärschlüssel= User_ID

Nein.
Daten in eigene Tabellen auslagern, hat immer dann Sinn, wenn die Daten mehrfach gebraucht und verwendet werden und wenn diese auch unter Umständen geändert werden.

Mal ein Beispiel: Wenn du den Namen in eine eigene Tabelle auslagern würdest, damit z.B. der Name Schmidt nur einmal vorkommt, dann hat das eigentlich keinen Sinn. Warum nicht? Wenn einer der User seinen Namen ändert zu Schmitt, dann gilt das nur für ihn, nicht für andere. Es ist in dem Sinne also keine Redundanz.

Wenn du aber zum Beispiel eine Abteilungszugehörigkeit in der Tabelle abbilden willst, wäre eine Tabellenauslagerung sinnvoll, denn die Namen der Abteilungen könnten sich ändern, es könnte auch eine dazukommen. In der Struktur könnte ein Feld Kürzel dazukommen oder gebraucht werden, etc...

Ich weiß nicht, ob ich es dir rüberbringen konnte. Zusammenfassend würde ich sagen, dass das auslagern von Tabellen nur dann interessant ist, wenn die ausgelagerten Daten veränderlich sind oder in einer 1:n - Beziehung zum Ursprung stehen oder extrem redundant sind. Postleitzahlen könnte man auch auslagern und es wäre theoretisch sogar sinnvoll, aber wahrscheinlich nicht praktikabel, außer bei einer Adressdatenbank.

Ich bin nicht so rochtig zufrieden mit meiner Antwort, aber vielleicht hilft es ja trotzdem weiter.

ciao
romy

[Rick]

Ich bin nicht so rochtig zufrieden mit meiner Antwort, aber vielleicht hilft es ja trotzdem weiter.

ciao
romy

Hi Romy,

doch, doch. Ich bin sehr zufrieden! Genau so wird ein Schuh draus!

Also würde ich einen Userstatus (aktiv/inaktiv) in die Haupttabelle integrieren, während ich einen Userstatus, der z.B. die Zugehörigkeit zu einer Altersklasse (alt/mittel/jung) bezeichnet, nur relational einbinde.

Macht sehr viel Sinn  und kam gut 'rüber.

Gibts eigentlich noch Unterschiede bzgl. Performance der Datenbank? Mal angenommen, es wäre einer zu faul und/oder unfähig, entsprechende Kreuzabfragen durchzuführen (nein, bin ich nicht und diese Art Abfragen  mache ich besonders gerne!), wäre seine Datenbank mit möglichst vielen Feldern in einer Tabelle langsamer als meine "echte" relationale datenbank??

Grüße, Rick

[Rick]

Siehste mal. Jatzt ist mir durch Deine Antwort sogar noch ein gutes Argument eingefallen, was für eine eigene Tabelle spricht.

Es wäre ja möglich, daß z.B. ein Kriterium, das sich auf einen User bezieht, nicht nur austauschbar, sondern sogar in unterschiedlicher Anzahl vorhanden wäre.

Beispiel:

Tabelle User enthält o.g. Grunddaten
Tabelle Bücher enthält alle Bücher eines Users in Relation zu ihm.

So wäre gegeben, daß die Datenbank weiterhin effektiv genutzt wäre, auch wenn User1 nur 2 Bücher hat, während User2 2000 Bücher hat..

Ja! So wird ein schuh draus.

Danke nochmal, Rick

[romy]

Hi Rick,

So wäre gegeben, daß die Datenbank weiterhin effektiv genutzt wäre, auch wenn User1 nur 2 Bücher hat, während User2 2000 Bücher hat..

Genau, dass meinte ich mit 1:n ;)
Das ist sicherlich auch der Hauptgrund, dass ganze relational aufzubauen. Alles andere ist schöner, wartbarer und sauberer, aber nicht zwingend. Bei diesem Beispiel ist es zwingend.

ciao
romy

[romy]

Hi Rick,

Gibts eigentlich noch Unterschiede bzgl. Performance der Datenbank? Mal angenommen, es wäre einer zu faul und/oder unfähig, entsprechende Kreuzabfragen durchzuführen (nein, bin ich nicht und diese Art Abfragen  mache ich besonders gerne!), wäre seine Datenbank mit möglichst vielen Feldern in einer Tabelle langsamer als meine "echte" relationale datenbank??

Das kommt ganz darauf an. Fakt ist, je mehr Kreuzfragen du hast bei vielen Datensätzen, desto performancelastiger wird das ganze.
Letztendlich gibt es m.E. viele Mittel zur Optimierung, die man dann einsetzen könnte. Bei großen Datenmengen sind sicherlich zusätzlich noch ein paar Viewtabellen sinnvoll, die Daten zusammenfassend darstellen.
Konkret ist es schwierig zu beantworten, ob die Daten in einer Tabelle oder die relationen Tabellen mehr Performance kosten, aber wahrscheinlich die relationalen Tabellen. Aber das ist nur geschätzt, dass weiß ich nicht sicher.
Ich habe bisher nur die Erfahrung gemacht, dass man bei großen Datenmengen (ab 500.000 DS) die Relationalität durchaus auch mal der Performance wegen hinten anstellen darf oder eben über redundante Zwischentabellen das ganze optimiert.
Das ist nur meine laienhafte Meinung.

ciao
romy

[Rick]

Hi Romy,

danke für die Antwort!
Was genau sind 500.000 DS? Die Abk. DS sagt mir nichts :-(

Grüße, Rick

P.S: Klasse Sache, das mit den Findeltieren!!! Habe selber einen Hund von "Tiere suchen ein Zuhause". Weißt Du, daß Dein Forum Status 403 hat?

Hi Rick,

Gibts eigentlich noch Unterschiede bzgl. Performance der Datenbank? Mal angenommen, es wäre einer zu faul und/oder unfähig, entsprechende Kreuzabfragen durchzuführen (nein, bin ich nicht und diese Art Abfragen  mache ich besonders gerne!), wäre seine Datenbank mit möglichst vielen Feldern in einer Tabelle langsamer als meine "echte" relationale datenbank??
Das kommt ganz darauf an. Fakt ist, je mehr Kreuzfragen du hast bei vielen Datensätzen, desto performancelastiger wird das ganze.
Letztendlich gibt es m.E. viele Mittel zur Optimierung, die man dann einsetzen könnte. Bei großen Datenmengen sind sicherlich zusätzlich noch ein paar Viewtabellen sinnvoll, die Daten zusammenfassend darstellen.
Konkret ist es schwierig zu beantworten, ob die Daten in einer Tabelle oder die relationen Tabellen mehr Performance kosten, aber wahrscheinlich die relationalen Tabellen. Aber das ist nur geschätzt, dass weiß ich nicht sicher.
Ich habe bisher nur die Erfahrung gemacht, dass man bei großen Datenmengen (ab 500.000 DS) die Relationalität durchaus auch mal der Performance wegen hinten anstellen darf oder eben über redundante Zwischentabellen das ganze optimiert.
Das ist nur meine laienhafte Meinung.

ciao
romy

[romy]

Hi Rick,

danke für die Antwort!
Was genau sind 500.000 DS? Die Abk. DS sagt mir nichts :-(

DS=Datensätze

P.S: Klasse Sache, das mit den Findeltieren!!! Habe selber einen Hund von "Tiere suchen ein Zuhause". Weißt Du, daß Dein Forum Status 403 hat?

Hatte lange nichts dran gemacht und dann feststellen müssen, dass es völlig zugespamt ist. Ich räume gerade auf. Danke!

Es wäre gut, wenn du dich direkt auf die Textzeilen der Antworten beziehst, wo du etwas dazu sagen möchtest. Die Fullqotes nehmen beim archivieren von Beiträgen sehr viel Platz weg und sind zudem unnötig. Danke schön!

ciao
romy

[Ilja]

yo,

nur mal am rande, eine relation bedeutet bezogen auf datenbanken eine tabelle. was ihr meint ist relationship für beziehung.

und kreuzabfragen, bzw. das kreuzprodukt meint ihr sicherlich auch nicht, sondern tabellen mit entsprechende join-bedinungen miteinander zu verknüpfen.

und views haben nichts mit datenmengen zu tun, sondern dienen dazu, bestimmte abfragen als objekt zu speichern.

und nicht die relationalität wird bei grossen datenmengen hinten angestellt, sondern es wird denormalisiert.

Ilja

[_King Lully]

und views haben nichts mit datenmengen zu tun, sondern dienen dazu, bestimmte abfragen als objekt zu speichern.

und nicht die relationalität wird bei grossen datenmengen hinten angestellt, sondern es wird denormalisiert.

Wenn ich nicht ohnehin schon aus bestimmten Gründen vor Wut im Dreieck springen würde, Dein Vortrag hätte es gebracht.
Muka muka-mässig so zu sagen.   ;)

[romy]

Hi Ilja,

danke, dass du dich zu Wort meldest. Ich habe meist nicht die Fachlichkeit um es korrekt zu beschreiben. Ich denke, es ist rausgekommen für den OP, was ich meine, aber für spätere Leser ist dein Beitrag der Wichtigste.

nur mal am rande, eine relation bedeutet bezogen auf datenbanken eine tabelle. was ihr meint ist relationship für beziehung.

Eine Frage hierzu, wie kann man das verdeutschen. Relationship ist eine Beziehung, dass wollte ich eigentlich auch sagen. Was ist das relation?

und kreuzabfragen, bzw. das kreuzprodukt meint ihr sicherlich auch nicht, sondern tabellen mit entsprechende join-bedinungen miteinander zu verknüpfen.

Ich hätte tatsächlich gedacht, dass Kreuzabfragen das deutsche Wort für Join-abfrage ist. Obwohl mit bewusst ist, dass die Kreuzabfrage nur ein Beispiel eines Joins ist, nämlich der Uneingeschränkte!?

und views haben nichts mit datenmengen zu tun, sondern dienen dazu, bestimmte abfragen als objekt zu speichern.

Ja, das war das falsche Wort. Hilf mir bitte, ich wollte ausdrücken, dass bei großen Datenmengen häufiger eine Art Zwischentabelle angelegt wird, wie nennt man das dann. Diese Zwischentabelle enthält dann Daten, die es schon gibt. Sie verkörpert z.B. ein häufig benutztes Select. Oder macht man das gar nicht mehr.

und nicht die relationalität wird bei grossen datenmengen hinten angestellt, sondern es wird denormalisiert.

Ja, das wollte ich sagen.
ciao
romy

[_King Lully]

Ich habe bisher nur die Erfahrung gemacht, dass man bei großen Datenmengen (ab 500.000 DS) die Relationalität durchaus auch mal der Performance wegen hinten anstellen darf oder eben über redundante Zwischentabellen das ganze optimiert.
Das ist nur meine laienhafte Meinung.

Du könntest ja mal als Übungsaufgabe irgendein zu unterstützendes Szenario (eine Schule, ein Geschäft?) ERM-mässig darstellen und normalisieren.

Täte zumindest mich brennend interessieren, was da so rauskommt.

[romy]

Hi _King,

Du könntest ja mal als Übungsaufgabe irgendein zu unterstützendes Szenario (eine Schule, ein Geschäft?) ERM-mässig darstellen und normalisieren.
Täte zumindest mich brennend interessieren, was da so rauskommt.

Schule
------

Schueler
--------
schueler_id (PK)
Name
Vorname
Straße
Hausnr
plz
Stadt
Geb.-Datum
Klassen_id (FK zu Klassen) // obwohl ich den nicht brauche, es aber so schneller geht ;)

Lehrer
--------
lehrer_id (PK)
Name
Vorname
Straße
Hausnr
plz
Stadt
Geb.-Datum

Klassen
-------
klassen_id
Name

LehrerKlassenZuordnung
---------------------
lehrer_id (PK)
klassen_id (PK)
klassenleiter bool

SchuelerKlassenZuordnung
----------------------
schueler_id (PK)
klassen_id (PK)
Klassenzimmernr.
klassenleiter_id (FK zu lehrer_id, wenn er als solcher definiert ist) brauche ich eigentlich auch nicht.

Meinst du das so?

ciao
romy

[_King Lully]

Yo, danke, danke auch für Deinen bewiesenen Humor. Mehr oder weniger bewiesen, habe ja noch nicht alles gelesen. Na, dann schaun mer mal...

Schule

Schueler

schueler_id (PK)
Name
Vorname
Straße
Hausnr
plz
Stadt
Geb.-Datum
Klassen_id (FK zu Klassen) // obwohl ich den nicht brauche, es aber so schneller geht ;)

Da sind schon einige Inkonsistenzen bei der Namensgebung, beachte Groß- und Kleinschreibung. Die Anmerkung zum FK 'Klassen_id' lässt uns schon etwas grau werden. Warum braucht man den FK denn bittesehr nicht?

Lehrer

lehrer_id (PK)
Name
Vorname
Straße
Hausnr
plz
Stadt
Geb.-Datum

Wieder Inkonistenzen bei der DF-Benamung. Sind Lehrer zufällig auch Klassenlehrer?

Klassen

klassen_id
Name

Was mitr hier gefällt ist, dass Du nicht Klasse_ID als Namen gewählt hast, sondern klassen_id. Das ist gut, denn viele Entitätennamen sind in Singular- und Pluralform identisch. D.h. Du kommst _nicht_ mit einer Regel, die nicht immer funktionieren würde.

LehrerKlassenZuordnung

lehrer_id (PK)
klassen_id (PK)
klassenleiter bool

Jo, eine "n:m" zwischen Lehrer und Klasse wg. Schulfachbelegung und Unterrichtsvertelung und so. (Gibts auch ne Unterrichts- und Notentabelle?)
'klassenleiter' scheint mir aber Murks zu sein. Mehrere Klassenlehrer für eine Klasse? (OK, solltest Du Dich auf das Kurssystem der Oberstufe beziehen, dann könnte was dran sein. ;)
Gibts eigentlich auch Schulfächer?

SchuelerKlassenZuordnung

schueler_id (PK)
klassen_id (PK)
Klassenzimmernr.
klassenleiter_id (FK zu lehrer_id, wenn er als solcher definiert ist) brauche ich eigentlich auch nicht.

Irgendwo ist da jetzt Murks. Zu viele Entitäten bzw. Zuordnungen. Vermutlich scheitert so ein Modell. Habe jetzt keine Lust weiter reinzugehen, _ohne_ dass Du vorher ein Datenbankdiagramm lieferst.

Meinst du das so?

Genau sowas, loge.

[Tim Tepaße]

Hallo,

'klassenleiter' scheint mir aber Murks zu sein. Mehrere Klassenlehrer für eine Klasse?

Auch das gibt es, dass eine Klasse im Tandem geleitet wird. Klassischer ist aber das Einzelkämpfer-Modell.

Tim

[wahsaga]

hi,

Also würde ich einen Userstatus (aktiv/inaktiv) in die Haupttabelle integrieren, während ich einen Userstatus, der z.B. die Zugehörigkeit zu einer Altersklasse (alt/mittel/jung) bezeichnet, nur relational einbinde.

Überlege dir, ob letzteres überhaupt in die DB gehört.

Zum einen _ergibt_ es sich aus dem Geburtsdatum - die Altersklasse, so du sie separat ablegst, würde also eine redundante Information darstellen.

Und zum anderen haben Nutzer die Angewohnheit, _älter_ zu werden - ein Attribut Altersklasse in der Datenbank abgelegt würde also fortwährend Updates erfordern. (Und ein Attribut Alter genauso.)

gruß,
wahsaga

[Rick]

Hallo Wahsaga,

Mir fiel gerade nichts anderes ein. Ansonsten ist Dein Einwand selbstredend korrekt!

Grüße, Rick

hi,

Also würde ich einen Userstatus (aktiv/inaktiv) in die Haupttabelle integrieren, während ich einen Userstatus, der z.B. die Zugehörigkeit zu einer Altersklasse (alt/mittel/jung) bezeichnet, nur relational einbinde.

Überlege dir, ob letzteres überhaupt in die DB gehört.

Zum einen _ergibt_ es sich aus dem Geburtsdatum - die Altersklasse, so du sie separat ablegst, würde also eine redundante Information darstellen.

Und zum anderen haben Nutzer die Angewohnheit, _älter_ zu werden - ein Attribut Altersklasse in der Datenbank abgelegt würde also fortwährend Updates erfordern. (Und ein Attribut Alter genauso.)

gruß,
wahsaga

[_King Lully]

Ich weiß nicht, ob ich es dir rüberbringen konnte. Zusammenfassend würde ich sagen, dass das auslagern von Tabellen nur dann interessant ist, wenn die ausgelagerten Daten veränderlich sind oder in einer 1:n - Beziehung zum Ursprung stehen oder extrem redundant sind. Postleitzahlen könnte man auch auslagern und es wäre theoretisch sogar sinnvoll, aber wahrscheinlich nicht praktikabel, außer bei einer Adressdatenbank.

Deine Einlassungen sind schon fast kriminell (habe noch den besten Teil zitiert ;), Tabellen werden keinesfalls gebildet um Redundanzen vorzubeugen, sondern weil unterschiedliche Wesen abgebildet werden. Geschäftslogik kennt Objekte, Beziehungen zwischen denselben und Abläufe (Projekte bzw. Prozesse).

[romy]

Hi _King,

Tabellen werden keinesfalls gebildet um Redundanzen vorzubeugen, sondern weil unterschiedliche Wesen abgebildet werden. Geschäftslogik kennt Objekte, Beziehungen zwischen denselben und Abläufe (Projekte bzw. Prozesse).

Bist du dir sicher? Ich kann es gerade nicht belegen und es könnte sein, dass ich das Wort Redundanz immer im falschen Zusammenhang sehe, aber ich meine schon, dass man damit auch Redundanzen vermeiden will.

ciao
romy

[_King Lully]

Tabellen werden keinesfalls gebildet um Redundanzen vorzubeugen, sondern weil unterschiedliche Wesen abgebildet werden. Geschäftslogik kennt Objekte, Beziehungen zwischen denselben und Abläufe (Projekte bzw. Prozesse).
Bist du dir sicher? Ich kann es gerade nicht belegen und es könnte sein, dass ich das Wort Redundanz immer im falschen Zusammenhang sehe, aber ich meine schon, dass man damit auch Redundanzen vermeiden will.

Erst kommt das ERM http://de.wikipedia.org/wiki/Entity_Relationship_Model, dann kommt der Rest http://de.wikipedia.org/wiki/Normalisierung_(Datenbank). Redundanzen vermeiden bei der Normalisierung, hmm?

Kann man so sehen, aber wenn das ERM OK ist, dann werden einzelne Stufen der beschriebenen Normalformen (die eigentlich ohnehin relativ uninteressant sind, d.h. bspw. wird bereits die erste oft bewusst nicht erreicht) bereits dort erreicht. Die Formulierung "Zusammenfassend würde ich sagen, dass das auslagern von Tabellen nur dann interessant ist, wenn die ausgelagerten Daten veränderlich sind oder in einer 1:n - Beziehung zum Ursprung stehen oder extrem redundant sind. Postleitzahlen könnte man auch auslagern und es wäre theoretisch sogar sinnvoll, aber wahrscheinlich nicht praktikabel, außer bei einer Adressdatenbank." liess mich gestern abend etwas blass werden.