SQL Wie Daten in MySQL speichern?

;) Ich sag doch: Es lässt sich alles bauen, aber es bringt doch jetzt mal ganz ehrlich 0 Vorteil.

Betrachten wir doch mal:
Er hat 20 Tabellen - ok, nicht wenig aber ok
Die Tabellen sind normalisiert (enthalten ja eh nur 3 Spalten oder minimal mehr)
Er hat Statistiken, die sich jeweils genau aus EINER Tabelle generieren (nix joint, nix verknüpft, nada)
Er hat verschiedene Daten in den Statistiken
Neue Statistik = neue Tabelle, na und? Sind ja eh neue Daten die mit alten Daten nix am Hut haben und womöglich total anderes Format haben.

Was verliert er durch das Design? Er hat weder überflüssige Infos noch Performance Probleme - ist doch ok.

Man könnte jetzt sogar noch argumentieren, dass er in der jeweiligen Tabellen den optimalen Datentyp wählen kann (float, int, varchar).
 
Ich habe dir sehr erhebliche Vorteile genannt, und du bestätigst diese sogar und sagst trotzdem dass es 0 Vorteile hat...

Ich weiss ehrlich gesagt nicht ob es in diesem Fall wirklich sinn macht weiter zu diskutieren, aber ei wenig halt ich noch durch...

Er hat Statistiken, die sich jeweils genau aus EINER Tabelle generieren (nix joint, nix verknüpft, nada)
Bei mir musst du nix joinen, sondern nur ein WHERE hinzufügen.
Davon agesehn.
1) Gleicht dieses kleine "where" sich locker flockig mit dem variablem tabellen Namen aus (vom arbeitsuafwand her)
2) Ist es ein schwerer Desginfehler, wenn man Variable Tabellen Namen hat.. (kann ich leider nicht durch ein Zitat beweisen, aber glaub in diesem Fall einfach mal meiner Erfahrung .. wenn du mich bezahlst begründige ich dir das alles gründlich!)
3) Ist das ein Argument das sich rein auf die Anzeige bezieht und in keinster weise auf die Datenhaltung.. so gesehn ist das Argument eh hinfällig, wenn es um einen guten Datenbankentwurf geht.
Ich empfehle dir bei dieser Denkweise Excel....
Code:
Er hat verschiedene Daten in den Statistiken
Die dem gleichem Schema folgen und folglich in eine Tabelle gehören.

HTML:
Neue Statistik = neue Tabelle, na und? Sind ja eh neue Daten die mit alten Daten nix am Hut haben und womöglich ein total anderes Format haben.
Nur weile Neue Daten hinzukommen muss man doch nicht unbedingt das Tabellenschema ändert.. Das Tabellenschema muss geändert werden wenn es neue Konzepte gibt.. es gibt aber keine neuen Konzepte, also sollte man am Tabellenschema nichts änern müssen.


Und was man durch dieses schrekcliche desig verliert habe ich bereits mehrfach gesagt und du hast es bestätigt aber vergisst das in der nächsten sekunde gleich wieder:
Sehr viel weniger aufwand, und eine hoch dynamische und sehr leicht erweiterebare Anwendung mit sehr geringem Änderungsaufwand.


Code:
Man könnte jetzt sogar noch argumentieren, dass er in der jeweiligen Tabellen den optimalen Datentyp wählen kann (float, int, varchar).
Ich bezweifle dass so etwas in diesem Fall gebraucht wird (wird benötigt wenn man innerhalb einer SQL anfrage mit diesen werten gerechnet werden muss (u.a.)).
Wird es jedoch doch gebraucht, dann kann man dies ein eine Werte Typ Tabelle auslagern, und behält trotzdem die freiheiten des Tabellenschemas, welches sehr dynamisch ist.



Trotzdem wäre es mal sehr interessant die genaue zusammenstellung der 20 Tabellen zu kennen..
 
Zuletzt bearbeitet:
Ich hab auch Datenbankvorlesungen gehört ;) Ich hab das ganze sogar schon erfolgreich hinter mir.
Ich denke einfach wir haben verschiedene Vorstellungen von den Daten die es hier geben könnte.
Du sagtest "Der Sinn und zweck von Tabellen ist es gleiche Sachen geordnet in Tabellen zu speichern." und ich bezweifel halt einfach, dass es sich bei den Daten, über die Statistiken erstellt werden, es sich um gleiche Daten handelt. Das ist aber alles recht spekulativ - es ist schließlich nicht unsere Anwendung. Du gehst vom gleichen Schema aus, ich nicht - das macht einen identischen Standpunkt schonmal schwer.

Dein Punkt 2 bezüglich "Designfehler mit variablen Tabellennamen" konnt meiner Meinung nach auch immer auf den Umstand an. Eigentlich sind seine Tabellennamen ja nicht sonderlich variabel - jede Statistik hat genau ihre Tabelle.

Auch die Dynamisierung ist irgendwie wieder Anwendungsabhängig. Es gibt unzählige Anwendungen denen die Datenhaltung total Wumpe ist, solang Sie unter dem selben Namen angesprochen werden kann. In diesem Fall kann auch eine Mehr-Tabellen-Haltung einfacher sein, als die integrierte Tabelle.
Es ist hier zu unterscheiden, ob ich auf Anwendungs- oder auf Datenhaltungsseite "einfacher" fahre (bzw weniger Aufwand habe).

In dem Fall den wir haben, sind auch Argumente wie Updaten relativ egal, weil es sich um "statische" Daten handelt. Wenn ich 1x im Jahr etwas ändere, ist es von praktischer Seite echt egal, in welcher Tabellenform ich das ganze halte - der Aufwand geht einfach unter, da er nur 1x im Jahr geschieht.

Auch musste ich im Job schon öfter merken, dass die theoretische Optimallösung oftmals nicht wirklich gewünscht wird, weil sie in Sachen Handlich Nachteile mit sich bringt. Ich sehe in dem Fall, in welchem die Datenbank etc ja eh schon steht und alles läuft, einfach nicht genug Nachteile, als dass sich große Änderungen praktisch(!!!!!) lohnen würden.

Aber ich stimme dir zu: Wenn wir alle 20 Tabellen sehen würden, wäre die Diskussion sicher interessanter.
 
Den Aufwand können wir hier halt nicht so wirklich gut abschätzen ;)
Für ihn wäre vielleicht eine neue DB + neuer GET Paramter sogar weniger Aufwand weil nur DB-Import und sonst nix ;)

Aber der Rest spielt echt nicht wirklich eine Rolle - wir "streiten" uns hier um etwas, was keiner von uns kennt, ist vielleicht auch nicht das effektivste an einem Donnerstagabend ;)
 
Zurück
Oben