So ich bin nun endlich dazu gekommen, Mikhal’s Vorschlag in
MySQL zu importieren.
Da ich aus verschiedenen Gründen
MySQL nutzen muss, und dort keine Generatoren zur Verfügung stehen, sehe ich das richtig das nun in jeder Tabelle das erste Feld, sprich das „ID“ also das Feld mit dem Primary Key drauf, auf auto increment gesetzt werden muss?
Jetzt wo ich das ganze vor mir habe und die Verknüpfungen der Tabellen untereinander sehe stellen sich mir weitere Fragen dazu:
Wie ist denn jetzt das vorgehen wenn man so eine Struktur hat auf der Programmiertechnischen Ebene?
1. Ich müsste ein
Query erstellen das die Verknüpfung der Tabellen untereinander berücksichtigt, die Felder auswählen, die zur Eingabe benötigt werden und in einer Maske anzeigen, die der Benutzer ausfüllen muss?
Also so was in der Art:
Code:
SELECT
Hier die Felder aus den verschiedenen Tabellen die ich zum Anzeigen und ausfüllen brauche?
FROM
kunden
INNER JOIN anschriften ON anschriften.ANS_KUN_ID = kunden.KUN_ID
INNER JOIN angebote ON angebote.ANG_KUN_ID = kunden.KUN_ID
INNER JOIN angebotspositionen ON angebotspositionen.POS_ANG_ID = angebote.ANG_ID
INNER JOIN einheiten ON angebotspositionen.POS_EIN_ID = einheiten.EIN_ID
INNER JOIN preise ON preise.PRE_EIN_ID = einheiten.EIN_ID
INNER JOIN produkte ON angebotspositionen.POS_ART_ID = produkte.ART_ID AND preise.PRE_ART_ID = produkte.ART_ID
2. Wie berechnet man die Preise und ggf. weitere Dinge wie Ablaufdatum des Angebots automatisch anhand der später vorliegenden Daten?
Ich hatte einige Tage zuvor, bevor ich mich an Euch gewandt hatte, ja selber immer wieder angefangen Tabellenstrukturen dafür zu erstellen und immer wieder auch verworfen. Was aber dabei raus kam, war dann die Idee mit einem VIEW wo ich dann so etwas gemacht hatte:
CAST(((`angebots_scheme`.`angebote`.`anzahl` * `angebots_scheme`.`artikel`.`ek_preis`) * `angebots_scheme`.`angebote`.`aufschlag`) AS DECIMAL (18 , 2 )) AS `G-Preis`
Wäre das einigermaßen sinnvoll, oder wie würdet Ihr so etwas machen?
3. Ich hoffe ich habe das nun einigermaßen kapiert, warum man weitere Tabellen anlegt und nicht alles z.B. in eine schreibt, dabei taucht dann wieder eine Frage auf:
Wenn man jetzt mal beim Mikhal die Anschriften Tabelle als Grundlage nehmen würde, wenn man dort nun ein Feld Postleitzahl hätte, was sich ja beim Umzug eines Kunden, immer wieder ändern würde, müsste ich dann eine Tabelle Postleitzahlen,Orte anlegen welche dann auf die Kunden Tabelle wiederum verweist, KUN_ID?
4. Bei Mikhal’s Model fehlt mir noch die Zonen Tabelle die aus 3 Feldern bestehen sollte:
ZON_ID, (PK)
ZON_BEZEICHNUNG (VARCHAR)
ZON_PREIS (DECIMAL)
Verstehe ich es richtig, wenn ich nun in der Kunden (oder Anschriften) Tabelle ein Feld KUND_ZON_ID anlege damit auf die Tabelle Zonen Feld ZON_ID verweisen muss?
Der Grund dieser Tabelle ist, das Anfahrtswege zum Kunden durch Zonen geregelt werden, z.B. Zone 1 wäre bis 25 KM oder so etwas in der Art, Preis 15,00€ pauschal, welche dann wiederum als Position Anfahrtskosten oder wie auch immer im Angebot auftauchen würde. Dies ist ja bei Umzug eines Kunden auch wieder ein Feld was sich verändern kann, daher der Gedanke zu einer weiteren Tabelle.
5. Die Angebote Tabelle von Mikhail besitzt das Feld Angebot Datum.
Wenn ich eine Gültigkeit für ein Angebot setzen möchte (von - bis) z.B. würde es reichen wenn (sofern die Idee mit meinem View für die Berechnungen richtig war)
das man dort z.B. das ANG_DATUM + (VerfallsTage) errechnen lässt?
Ich habe darüber nachgedacht ob ich später in den Tabellen Datensätze löschen soll oder nicht, irgendwie macht mir das Sorgen, deshalb dachte ich, ist es vielleicht ok, wenn man das nicht macht (aus Angst auf irgendwelche Probleme zu stossen die ich noch nicht kenne, weil mir dazu die Grundlagen fehlen) das man einfach nur ein flag setzt (aktiv 0,1) und so dieses Angebot oder was auch immer später im
Query beim abrufen der Daten über Where Klausel einfach berücksichtig. So tauchen diese Daten eben nicht mehr auf für den Benutzer sind aber weiterhin vorhanden in der Tabelle.
So würde ich es dann beim Ablaufdatum eines Angebotes machen, View hat das Ablaufdatum errechnet, ich schaue über ein
Query in der Angebot Tabelle nach und setz aktiv auf 0
6. Die Angebotspositionen nehmen den Preis auf, eine Änderung des Preises in der Preistabelle wird sich dann nicht auf das Angebot auswirken. Darüber hinaus habe ich in der Preistabelle die Möglichkeit geschaffen, einen Gültigkeitszeitraum für den Preis zu definieren.
Was heißt das genau für mich, wenn ein Preis seine Gültigkeit erreicht hat setz ich das PRE_GUELTIG_BIS auf das entsprechende Datum? Ich kenne im Vorfeld ja nicht den Gültigkeitszeitraum, was ist wenn dieser erreicht ist, muss dann ein neuer Preis hinterlegt werden? Oder wie soll das gemacht werden, dass ist mir nicht klar im Moment.
7. Die Anschrift besitzt ein Feld Anschrifttyp, der als SmallInt definiert ist (1=Lieferadresse, 2=Rechnungsadresse, 3=abweichende Lieferadresse...), kann man auch über eine Nachschlagetabelle realisieren.
Wie ist das genau gemeint, bzw wie wird das gemacht, ist ebenfalls noch nicht ganz klar.