Wieder mal die Tabellenstrukturen

[stOrM]

Zitat von Olli73:

Zitat von stOrM:

Können wir das mal Schritt für Schritt durchgehen bitte?

1. Also die Felder wie z.B. KundenPK (ist für mich als Stütze gedacht, ist also die ID aus der Tabelle Kunden und ist Primary Key, so hab ich das definiert in der Tabelle)
2. In Angebote gibt es zum jetzigen Zeitpunkt

Ein Feld, Bezeichnung

Ich wiederhole das kommt da jetzt raus und in die Tabelle Positionen rein, sowie auch Artikelbezeichnung (was im Moment in Tabelle Produkte gewesen wäre, dass kommt da jetzt auch weg?
Dort gibt es noch ein Preis Feld das kommt nun auch in Positionen?

Hab ich was vergessen?

Zu 1: Und das Feld KundenId ist dann die KundenNr? Dann hat mich nur die Bezeichnung verwirrt.

Zu 2: Bezeichnung in Angebot benötigst du nur, wenn das ganze Angebot eine Bezeichnung bekommen soll (evtl. gar nicht so dumm). Sei es um dem User anzuzeigen um was es sich bei dem Angebot handelt oder um anstatt der Überschrift "Angebot" z.B. "Angebot für ..." beim Drucken anzuzeigen.
Artikelbezeichnung, Preis etc. verbleiben in der Tabelle Artikel/Produkte und werden zusätzlich in die Tabelle Positionen aufgenommen.

1. Ja Korrekt!
2. Oh da hab ich durch einen Zufall eine gute Idee eingebaut von der ich nicht wusste, die aber gut finde, dann lass ich die Bezeichnung da drin. ! Alles klar, bastel ich mal eben rein.

[stOrM]

Schau mal bitte Olli, neue Struktur.

[p80286]

Zitat von stOrM:

Das Problem ist doch das ich es nicht weiß wie die Tabellen richtig gestaltet werden müssen, wenn ich das wüsste könnte ich das ja berücksichtigen.
Also fällt wohl Variante 1 raus, die Preise können sich täglich ändern.

Du mußt wissen welche Daten Du benötigst, und welche sich ändern könnten etc.
Der Datenbankdesigner macht dann daraus Tabellen....

Und wenn er "AngebotsID" und "ProduktPK" fröhlich durcheinander nutzt, muß er schon ganz gut sein um das so entstandene Chaos in 3 Monaten auf den ersten Blick zu überschauen.
Aber warum einfach wenn es auch kompliziert geht. (Du bist übrigens nicht der einzige, der so arbeitet)

Gruß
K-H

[stOrM]

Zitat von p80286:

Zitat von stOrM:

Das Problem ist doch das ich es nicht weiß wie die Tabellen richtig gestaltet werden müssen, wenn ich das wüsste könnte ich das ja berücksichtigen.
Also fällt wohl Variante 1 raus, die Preise können sich täglich ändern.

Du mußt wissen welche Daten Du benötigst, und welche sich ändern könnten etc.
Der Datenbankdesigner macht dann daraus Tabellen....

Und wenn er "AngebotsID" und "ProduktPK" fröhlich durcheinander nutzt, muß er schon ganz gut sein um das so entstandene Chaos in 3 Monaten auf den ersten Blick zu überschauen.
Aber warum einfach wenn es auch kompliziert geht. (Du bist übrigens nicht der einzige, der so arbeitet)

Gruß
K-H

Amen... Sehr konstruktiv, dann hast Du sicherlich am Anfang alles sofort richtig gemacht denke ich mal. Respekt!
Allerdings verstehe ich den Einwand grad nicht wie soll ich die ID mit der PK durch einander würfeln, deshalb steht bei dem einen ja ID und beim anderen PK, kann aber auch sein das ich Dir jetzt nicht folgen kann.

[Olli73]

Zitat von stOrM:

Schau mal bitte Olli, neue Struktur.

Sieht auf den ersten Blick ganz gut aus. Nur die Einheiten hast du glaube ich noch nicht verwendet. Die müssten mindestens in die Produkttabelle.

[stOrM]

Zitat von Olli73:

Zitat von stOrM:

Schau mal bitte Olli, neue Struktur.

Sieht auf den ersten Blick ganz gut aus. Nur die Einheiten hast du glaube ich noch nicht verwendet. Die müssten mindestens in die Produkttabelle.

Ok hab ich nun.

[Jumpy]

Ich weiß ja jetzt nicht, ob das nur ein Übungs-Projekt ist, oder es um was konkretes geht?
In letzterem Fall müsste man sich ggf. noch Gedanken machen:
- Gültigkeit eines Angebotes (ala "An dieses Angebot halten wir uns bis zum XXX gebunden")
- Varianten oder Alternative Positionen (gibts bei Handwerkern oft)

[jobo]

Zitat von Jumpy:

Ich weiß ja jetzt nicht, ob das nur ein Übungs-Projekt ist, oder es um was konkretes geht?
In letzterem Fall müsste man sich ggf. noch Gedanken machen:
- Gültigkeit eines Angebotes (ala "An dieses Angebot halten wir uns bis zum XXX gebunden")
- Varianten oder Alternative Positionen (gibts bei Handwerkern oft)

Ich finde das Modell von Mikal ganz gut. In Bezug auf Jumpys Anmerkungen würde ich da den einzigen Knackpunkt sehen im Bereich Angebotsgültigkeit und Preisgültigkeit. Das kann sich so wie es modelliert ist widersprechen, sofern eine Angebotsgültigkeit eingesetzt wird (ist ja nicht unüblich)
Auch ist der Fehler mit dem Gesamtpreis aus dem 1. Modell raus. Der wird errechnet, nicht abgelegt.

[haentschman]

Hallöle...
Da sind ja gute Anworten dabei...

Zitat:

Allerdings verstehe ich den Einwand grad nicht wie soll ich die ID mit der PK durch einander würfeln

Der Einwand ist folgender. Ein Feldname sollte sinngemäß den Inhalt darstellen. ProduktPK ist die eindeutige ID des Datensatzes in der Produkt Tabelle. Das Feld, in der Produkt Tabelle, muß ja nicht unbedingt einen PK haben. Der PK ist ein "Zustand" des Feldes und hat damit nichts im Namen verloren. Deshalb besser ProduktID...