SQL Absatz-Tabelle je Mitarbeiter je Monat

[Konkel]

Guten Morgen,

ich plane gerade eine kleine WebApp (MySQL, PHP), mit der ich folgendes realisieren möchte:

Eine Möglichkeit zur Eingabe der verkauften Produkte (wie im Screenshot ersichtlich ist).
Diese Tabelle möchte ich für alle Monate des Jahres haben, jeweils für die einzelnen
Mitarbeiter.

Wie gehe ich da am besten ran? Für jeden Mitarbeiter eine eigene Tabelle in die Datenbank
einbinden, macht da eher wenig Sinn, oder? - Ist dies vielleicht doch die beste Möglichkeit?

Ich freue mich auf euren Input. Mir geht es hauptsächlich um das Datenbankdesign.

Grüße, Konkel

 

[PHuV]

Ist das was produktives oder eine theoretische Aufgabe in Form einer eine Hausaufgabe etc.?

 

[Lawnmower]

Naja wenn das sauber erfasst ist in der DB, kannst Du ja nach Mitarbeiter filtern und dann jeweils nach Produkt und verkaufte Anzahl pro Tag, Monat und Jahr (gespeichert in ein Datumfeld) gruppieren/sortieren.
Genauer kann man das nicht beantworten wenn man die DB Struktur nicht kennt.

 

[SoDaTierchen]

Spalten sind etwas, was in SQL-Tabellen nicht regelmäßigen Änderungen unterworfen werden sollte. Zeilen hingegen sind auch in großer Stückzahl noch Performance. Grundsätzliche Überlegungen bei SQL-Tabellen sind also immer: Welche Spalten brauchst du, um den Sachverhalt abzubilden. Eine Spalte je Produkt ist nur sinnvoll, wenn sich die Produkte nie ändern.

Bevor ich weiter helfe: Bitte den Kontext angeben: Produktiv oder schulisch?

 

[Konkel]

Es soll tatsächlich was produktives werden.

Die Produkte bleiben immer die gleichen.
Mein Kollege hatte es jetzt so umgesetzt, dass jeder Mitarbeiter eine eigene
Tabelle hat in dieser bereits Zeilen für jeden Tag bis zum Ende des Jahres einge-
bunden sind, die dann jeweils geupdatet werden. Als Spalten dann die jeweili-
gen Produkte. Halte ich aber für zu viel des Guten. Eine bessere Idee hätte
ich leider aber aktuell auch noch nicht.

 

[DonConto]

Ich würde sagen, dass es am sinnvollsten ist drei Tabellen zu nehmen:
Parameter der Mitarbeiter (ID, Name, Vorname, etc)
Parameter der Produkte (ID, Kurzname, Bestellcode, etc)
Parameter der Verkäufe (ID, Mitarbeiter ID, Produkt ID, Anzahl Verkäufe, Datum, etc)

Mag für ein kleines Projekt oversized sein, sollte aber flexibel sein und damit gut skalieren. Der Grips steckt dann im Programmcode und den SQL Abfragen.

 

[new Account()]

Mag für ein kleines Projekt oversized sein, sollte aber flexibel sein und damit gut skalieren.

oversized, warum?

PS: Aus Flexibilität folgt nicht zwangsläufig Skalierbarkeit.

 

[DonConto]

oversized, warum?

Naja, man könnte das ja auch mit einer Tabelle abfrühstücken.

PS: Aus Flexibilität folgt nicht zwangsläufig Skalierbarkeit.

Nicht zwangsläufig, das stimmt.

 

[Lawnmower]

Genauso wie es @DonConto vorschlägt, würde ich es auch machen. Oversized finde ich nicht - man kann schöne und einfache SQL Abfragen darüber machen, es ist performant und sauber für zukünftige Weiterentwicklung.

 

[Gurkenraspel]

Du solltest dir zunächst mal die Regeln der Normalisierung anschauen, das sind erstmal die Grundprinzipien einer relationalen Datenbank (mysql ist eine davon). Größter Vorteil ist wohl die Vermeidung von Redundanzen, die im schlechtesten Fall zu inkonsistenzen deiner Daten führen...

https://de.wikipedia.org/wiki/Normalisierung_(Datenbank)