1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

MySQL: Frage zum Tabellen Volumen!

Dieses Thema im Forum "PHP & Co." wurde erstellt von Saio, 11.11.09.

  1. Saio

    Saio Jonathan

    Dabei seit:
    22.06.09
    Beiträge:
    83
    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
     
  2. ayxayx

    ayxayx Gala

    Dabei seit:
    23.10.09
    Beiträge:
    49
  3. Saio

    Saio Jonathan

    Dabei seit:
    22.06.09
    Beiträge:
    83
    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)
     
  4. ayxayx

    ayxayx Gala

    Dabei seit:
    23.10.09
    Beiträge:
    49
    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.
     
  5. creative7even

    creative7even Jerseymac

    Dabei seit:
    23.02.05
    Beiträge:
    454
    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 :) )
     

    Anhänge:

  6. Saio

    Saio Jonathan

    Dabei seit:
    22.06.09
    Beiträge:
    83
    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.
     
  7. ayxayx

    ayxayx Gala

    Dabei seit:
    23.10.09
    Beiträge:
    49
    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.
     
  8. Saio

    Saio Jonathan

    Dabei seit:
    22.06.09
    Beiträge:
    83
    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
     
  9. Achim74

    Achim74 Tydemans Early Worcester

    Dabei seit:
    19.12.06
    Beiträge:
    399
    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.
     
  10. naich

    naich Pommerscher Krummstiel

    Dabei seit:
    22.11.08
    Beiträge:
    3.059
    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.)
     

Diese Seite empfehlen