MySQL: Frage zum Tabellen Volumen!

[Saio]

Servus,

Wir stecken bei uns in der Uni gerade mitten im Softwarepraktikum und müssen in Java eine Teilnehmersoftware entwickeln bei der zwei verschiedene "Teilnehmer"-Arten verwaltet werden müssen, und noch vieles mehr....

Nun stoßen wir auf ein Problem!

Ursprünglich wollten wir in MySQL eine Große Tabelle mit allen Teilnehmerdaten erstellen, dabei würde es sich um eine Tabelle mit 94 Spalten handeln.

Davon wurde uns aber abgeraten, da wir damit die Datenbank "sprengen" würden.

Also sollten wir die Daten auf mehrere Tabellen aufteilen, damit ist allerdings, in der so schon knapp bemessenen Zeit, eine erhöhter Programmieraufwand verbunden.

Nun will ich einfach wissen ob das bei heutiger Technik nicht egal ist, ob ich nun eine große Tabelle habe oder mehrere kleine, wobei die Menge der Daten bei kleinen Tabellen durch die Schlüsselwerte steigen würde?!

MfG Max

[ayxayx]

Ein Projekt mit einer sochen Tabelle würde ich, wenn ich ein Dozent wäre sofort durchfallen lassen.

Damit würdet ihr die wichtigsten Regeln in dem Umgang mit relationellen Datenbanken misachten. Schaut euch mal das hier an:
http://de.wikipedia.org/wiki/Entity-Relationship-Modell
und dann noch das hier:
http://de.wikipedia.org/wiki/Normali...28Datenbank%29

Und überdenkt euer Vorhaben dann noch mal.

[Saio]

Das Problem ist aber, dass bei diesen 94 Daten zu jedem Teilnehmer die meisten immer unterschiedlich sind. Es gibt kaum Attributwerte, die bei einem Teilnehmer nochmals auftaucht. Ist es dann trotzdem sinnvoll das in mehrere Tabellen zu gliedern?
(Die, die mehrmals auftauchen, haben wir schon in Tabellen gegliedert und dann nur mit Fremdschluesseln in die grosse Tabelle integriert)

[ayxayx]

Was sind denn das für Daten die Ihr da abspeichert? Ich kann mir eigentlich kaum vorstellen, dass sich die Tabelle nicht weiter zerteilen ließe.

[creative7even]

Das Ziel der Lehrveranstaltung ist nach meinen Einschätzungen ganz klar: Normalisieren!
Wie mein Vorredner schon angemerkt hat -> alles in eine Tabelle zu stopfen wäre (und da bin ich mir sicher ohne die zu speichernden Daten zu kennen) die falsche Lösung.

Um das Ziel etwas greifbarer zu visualisiern gehen wir von zwei Teilnehmern aus - bspw. John und Max. Beide haben vermutlich einen Wohnort - dieser kann sich von Teilnehmer zu Teilnehmer unterscheiden - muss er aber nicht. Angenommen John und Max wohnen beide in München so müsste man diese Information redundant in die Spalte Wohnort ablegen (also bei Max und bei John jeweils den String/VARCHAR "München"). Der Ansatz wäre diese Information in eine weitere Tabelle, sagen wir zB.: <Wohnort>, auszulagern. Dort wird München nur einmal abgelegt. Per Verweis auf den Primärschlüssel der Tabelle <Wohnort> kann man nun vom <Teilnehmer> auf <Wohnort> referenzieren (siehe UML).

Verwendet ihr für die Aufgabe einen OR-Mapper?

(PS: Hoffe das war nicht zu Anschaulich - will niemanden beleidigen )

[Saio]

Das ist alles richtig mit der Normierung. Aber wir sehen bei unserem Problem einfach keinen Grund das zu normieren, bzw. es bietet sich nicht an.
Hier nochmal genaue Informationen zu den Daten, vlt. denken wir ja auch falsch.
Wir sollen in diesem Semester eine Software schreiben, die die Teilnehmer der Austauschprogramme Erasmus und Leonardo verwaltet.
Zu jedem Teilnehmer werden grob gefasst folgende Daten gespeichert:
Name, Vorname, Geburtstag, Geschlecht, Wohnadresse am Studienort,
Wohnadresse im Notfall, Wohnadresse am Praktikumsort, Heimatadresse, Bankverbindung,
Studiengang, verschiedenen Angaben fuer Ansprechpartner am Praktikumsort, Dauer des Praktikums,
Praktikumszielland, Abschluss, besuchte Universitaet,
Kostenstelle, Projektnummer, Foerdungssumme
(Jede Adresse ist natuerlich in die einzelnen Adressenkomponenten gegliedert)
Nach unserer Meinung koennen nur das Praktikumszielland, der Abschluss und die besuchte Universitaet normiert werden, was wir auch bereits gemacht haben.
Alle anderen Daten aendern sich mit jedem Teilnehmer zu unterschiedlich, als das man alle Eventualitaeten in einer eigenen Tabelle erfassen koennte. Macht dann das Aufsplitten der Daten in mehrere Tabellen, also das Normieren ueberhaupt Sinn? Uebersehen wir irgendwas?
Ist die Datenbank mit einer so grossen Tabelle wirklich ueberfordert?
Wenn die Informationen zu einem Teilnehmer aufsplitten, muessen wir ja auch alle Tabellen ueber Schluessel verknuepfen - logisch. Nur sind wir der Meinung, dass das irgendwie auch das Arbeiten mit den Daten beim Programmieren erschwert - zumindest fuer unseren Fall.

[ayxayx]

Ich komme bei deiner Aufzählung auf 8 bis 9 Tabellen. Bei der Normierung geht es nicht nur darum tatsächlich gleiche Daten auszulagern sondern auch gleichartige. Es macht z.B. Sinn für jede Art des Wohnortes eine eigene Tabelle anzulegen. Die Wohnorte könntest du dann nochmals Normalisiehren wie es creative7even in seinem Beispiel tut. Ich kann dich nur nocheinmal an die Normalisierungsregeln verweisen, ich habe nicht das Gefühl, dass du die Regeln angewendet hast. Regeln 1 bis 3 reichen aus. Lies dir die zweite Normalisierungsregel nochmal ganz genau durch.

[Saio]

Ok, danke euch allen für euer Feedback,

das Thema der Normierung fiel bei uns etwas mau aus, wenn es überhaupt erwähnt wurde.
Wir werden uns damit noch einmal genauer beschäftigen!

Vllt. taucht ja noch die ein oder andere Frage auf, dann könnt ihr uns vllt. weiter helfen.

MfG Max

[Achim74]

Wobei krampfhaft "Zu-Tode-Normalisieren" in der Praxis auch oft mit (vor allem Performance- und Usability-) Nachteilen verbunden ist. Kommt echt auf die Daten und was man damit abbilden will an ...

Edit: in Eurem Fall würde ich evtl. die Adressdaten auch redundant speichern und wichtige Suchfelder mit Indices ausstatten. Aber ohne Gewähr .. habe es nur oberflächlich betrachtet.

[naich]

Ja. Ich würde jetzt auch nicht unbedingt den Wohnort in ne extra Tabelle packen.
Eher evt. inhaltlich trennen, zB. alle Personen-Daten in eine Tabelle und alle Praktikumsdaten in eine Andere (auch wenn das dann evt. nur ne 1:1-Relation wird, ich weiß nicht, was das für Daten genau sind.)