SQL Wie Daten in MySQL speichern?

Und was genau ist daran schlecht? Das Problem, welches bei 2NF geschildert wird, ergibt sich bei mir nicht, sonern doch eher bei DerEineDas Version.
PW-toXic schrieb:
Das mit dem 3-mal ändern ist übrigends falsch.. das ist ein SQL Befehl, und da auf Jahr hoffentlich ein index ist, ist dieser Befehl auch nicht langsamer.
Damit wäre das in Wikipedia geschilderte Problem, bei dem der Albumtitel geändert wird, also hinfällig.

Der Unterschied zwischen daten1/2 und geraet1/2 ist, dass daten1 bspw. Geschwindigkeitsangaben zu geraet1 sind und daetn2 die Angaben zu geraet2.
 
Zuletzt bearbeitet:
Ich sage nicht, dass meine Version perfekt ist. Aber sicherlich viel besser als die Ausgangsvariante. Dass das Jahr mehrmals gespeichert wird finde ich auch weniger schön. Aber das kann man wiederrum in eine Tabelle auslagern und mit Fremdschlüssel verknüpfen. Wie das genau aussieht lasse ich aber hier mal offen. Ich rate dir einfach mal frei zu einem guten Datenbank-Tutorial, denn in meinen Augen benutzt du ein relationales DBMS ohne die Vorteile von Relationen zu erkennen und zu nutzen. Deine Datenstruktur erinnert mich viel mehr an eine Sammlung loser Excel-Tabellen, wo der Benutzer sich die gewünschte Datei auswählt.

Du scheinst sowieso einer Änderung eher skeptisch gegenüber zu stehen, und weil ich momentan genug mit meinem eigenen DB-Projekt zu tun habe, werde ich meine Gedanken hier erstmal nicht weiter ausführen.
 
Vielleicht kann mir ja mal jemand verraten, was genau schlecht ist an meiner Version und wieso man es anders machen sollte.

Jeder sagt, dass die Variante schlecht ist, aber nicht, wieso eigentlich und verweist dann auf Wikipedia, wo ich aber nicht wirklich eine Verbindung zu meiner Struktur bzw. Probleme die sich ergeben sollen, finden kann.
 
Ich glaube die Daten seht ihr auf seiner Webseite (der "Die Welt ist eine Scheibe" Link) unter Statistik.

Da die Dinger in meinen Augen überhaupt gar nichts miteinander zu tun haben und so auch überhaupt nie gejoint werden, weiß ich nicht warum ihr die alle in eine Datenbank steckt und das ganze als einheitliche Datenquelle seht.

Die "alles in eine Tabelle" Lösung geht doch schon bei den Transitoren in den Wald, weil es dort ja Daten1 und Daten2 gibt. OK, da es verschiedene Geräte sind kann man das mit 2 Einträgen in der einen Tabelle lösen.
Was macht die große Tabelle aber, wenn du z.b. Jetzt sowas speichern willst:
Jahr Gerät Daten_Jahresanfang Daten_Jahresende
?

Da es jeweils andere Stats sind bleib ich bei der Meinung, dass es nicht schadet das jeweils in eigenen Tabellen abzuhandeln.

Das die Tabelle direkt aus nem _GET Parameter geholt wird überlesen wir besser mal, da stimm ich zu ;)
 
Nö, die DB hat nichts mit GET am Hut :)

Und in der SQL-Abfrage arbeite ich auch mit my_real_escape_string - aber vermutlich wird mir gleich jemand sagen, dass das trotzdem doof ist :p
 
Zuletzt bearbeitet:
Das ist trotzdem doof.

Seh ich das richtig, dass es immer zu jedem jahr genau drei Wertepaare Gerät -> Daten gibt?
In diesem Fall ist eine Lösung in Ordnung, da das Argument mit der 2. Normalform nichtmehr gilt:

Code:
id	jahr	geraet1	daten1	geraet2	daten2	geraet3	daten3

jedoch ist dann "id" überflüssig.
 
Zuletzt bearbeitet:
Das mit den einzelnen Tabellen ist schon ganz alleine deswegen doof, weil man für jede neue Statistik eine neue TABELLE(!!) erstellen muss! Das will ich sehen, wie du das automatisierst.
 
@ PW-toXic: nein, es können unterschiedliche viele Gruppen auftreten.

@ DerEineDa: normalerweise kommen keine Daten mehr dazu. Falls doch, dann könnte ich das aus einer Wertetabelle mit jahr, daten, geraet etc. auch schnell durch ein Excel-Makro jagen und ein sql-File für eine neue Tabelle erstellen.



Und solange meine Lösung nur doof ist, aber es nichts weniger Doofes gibt, ist das die beste Lösung :)
 
Zuletzt bearbeitet:
@DerEineDa
Wenn die Daten aber doch gar nix miteinander zu tun haben?

Auf der Halbleiter-Seite (wäre schön zu erfahren, ob es um die Stats geht...) gibts z.B. Stats zu Fertigungskosten pro Transistor (über Jahre verteilt) und die hier angesprochenen Jahr / CPU / Anzahl Transistoren.
Das hat doch alles nicht wirklich was miteinander zu tun. Warum dann alles mit Gewalt in eine Tabelle donnern?
 
warum also genau 3 mal gerät->daten?

wenn du zb folgenden eintrag in der Tabelle hast:
1790 GTX260 1000 GTX 270 1200 GTX 280 1400

und du möchtest noch hinzufügen:
1790 GTX 290 1600

dann musst du ja folgenden Eintrag hinzufügen:

1790 GTX 290 1600 null null null null

Dass das schlecht ist sagt einem der normale Menschenverstand ;)


Das hat doch alles nicht wirklich was miteinander zu tun. Warum dann alles mit Gewalt in eine Tabelle donnern?
Warum mit Gewalt gleiche Sachen in 20 Tabellen donnern?
Davon abgesehn wurde deine Frage bereits beantwortet: Weil man dann unter anderem für neue Daten nichts am Tabellenschema ändern muss. Und das Tabellenschema sollte so selten wie möglich geändert werden. Der Sinn und zweck von Tabellen ist es gleiche Sachen geordnet in Tabellen zu speichern. Wie man diese darstellt hat mit der Datenhaltung nichts zu tun.
Es macht ja durchaus sinn all diese Dinger auf einer Webseite in 20 anzeige Tabellen anzuzeigen indem man ein sql befehl macht wie zb: select * from daten where type = prozessor... whatever
 
Zuletzt bearbeitet:
deshalb ja extra tabellen für statistiken die auch mehrere Werte haben ;) Da gibts dann auch keine null-Felder
 
Die Null Felder gibts bei der extrem einfachen Tabelle:
Code:
Jahr gerät Daten
auch nicht

Nur dass diese Lösung um Faktor 20 einfacher ist.
man braucht nur eine Tabelle anstatt 20 und insgesamt nur 3 anfragen für select update und insert anstatt von 60
also wenn das mal kein schlagkräftiges argument ist, dann weiss ich auch nichtmehr...
 
Zuletzt bearbeitet:
wenns kein Gerät gibt? (die Statistik von seiner Seite mit Fertigungskosten)
wenn ich Verschiedene Formaten von Daten haben kann?
Wenn ich für ein Gerät für ein Jahr zwei Einträge machen will? (Mein Beispiel mit Wert Jahresanfang/Ende)
Was ist "Daten" wenn ich sowohl ne Statistik über CPU-Speed von Gerät X als auch von Kosten von Gerät X haben will?

Ich stimme euch voll zu, dass das alles in EINE Tabelle gehört, wenn die jeweiligen Statistiken auf die selben Daten zurückgreifen. Aber wenn es doch total verschiedene Dinge sind, macht es nicht wirklich sinn.

Ihr müsst auch was über den Tellerrand rausblicken, dann seht ihr das Daten ja immer eine andere Bedeutung hat.
 
was unzählige NULL gibt, wenn Quartal nicht gebraucht wird

Klar gibts Lösungen zum drumherum bauen - aber ich bleib bei der "Wenn es unterschiedliche Daten sind mach doch eine Tabelle".

Hätte Mr.Snoot in seinem Screenshots die "Daten" Spalte jeweils Flops, Transistoren oder wasauchimmer das im ersten Beispiel sein soll, hätte wohl auch keiner geschrieben, dass man das alles in eine Tabell packen soll.
 
Zurück
Oben