Wieder mal die Tabellenstrukturen

[stOrM]

Moin,
ich bräuchte mal wieder Hilfe bezüglich einiger Tabellen die ich anlegen muss da weiß ich im Moment nicht was in welcher Tabelle stehen muss und wie sich das ganze verknüpfen soll.
Im Grunde geht es darum ein Angebot zu erstellen, mit folgender Struktur die vom Benutzer ausgefüllt werden soll:

1. Laufende Nummer
2. Bezeichnung
3. Menge
4. Einheit (Kg, m2, Std usw...)
5. E-Preis
6. G-Preis

Soweit so gut, jetzt dachte ich lege ich erstmal zum Test 3 Tabellen an:

Kundentabelle
Produkte
Angebote

Dabei tritt aber folgendes Problem auf, als Bezeichnung können z.B. auch Anfahrtskosten stehen. Jetzt weiss ich nicht soll ich die mit in die Produkttabelle aufnehmen, oder z.B. so etwas machen:

Zonen-Tabelle
Zone1 / Preis
Zone 2 / Preis
Zone 3 / Preis

Dann gehts weiter was ist mit den Einheiten?
Da brauche ich ja dann noch eine Tabelle für die verschiedenen Einheiten?

Also hab ich jetzt schon
Kunden,
Produkte
Einheiten
Zonen

Wenn ich das in Felder aufspalte, dann hab ich jetzt in etwa so etwas (nicht alle Felder aufgeführt, nur grob umrissen)

Kundentabelle
pk
kundennr
kundenname
....

Produkttabelle
pk
bezeichnung
e-preis
produkt
artikelnr
artikelnr_intern

Zonentabelle
Zone1 / Preis
Zone 2 / Preis
Zone 3 / Preis

Einheitentabelle
pk
bezeichnung_einheit

Angebote
pk
angebotsnummer
kundennummer
laufendenummer
bezeichnung
menge
leistungsdatum

Im Grunde müsste ich einmal wissen, welche Tabelle muss welche Felder aufnehmen und wie müssen die Tabellen zwingend verknüpft werden.
Ich hab zwar eine Menge dazu gelesen, aber leider keine Beispiele gefunden, die ich sinnvoll hätte nachvollziehen können.

Ich hab das jetzt schon zig mal versucht, bin aber immer wieder gestolpert.
Erst hab ich gar nichts verknüpft, nur über Joins mir die Sachen zusammen gesaugt, was zwar geht, aber so ist es bestimmt nicht im Sinne des Erfinders.
Dann hab ich mit PK und FK rumgefummelt, was zu diversen Problemen geführt hat, ich konnte plötzlich keine Daten mehr eingeben (update war nicht erlaubt, wegen meiner Verknüpfungen bis auf die Kundentabelle mit der durfte ich weiterhin alles machen)

Verknüpft war es in etwa so das aus der Angebotstabelle sich ein Feld auf die Kundennummer in der Kundentabelle bezog, die Produkttabelle mit Ihrer Produktnummer auf die Angebotstabelle mit dem Feld Produktnummer usw. jedenfalls völliges Chaos.

Mal generell noch eine Frage zur Verknüpfung.:

Geht so etwas automatisch das wenn man in der Angebotstabelle z.B. unter Artikelbezeichnung einen Artikel eingibt, das in der Angebotstabelle automatisch beim E-Preis der Preis steht oder muss ich dann ein weiteres Query ausführen im Hintergrund welches mir den Preis zum Produkt ermittelt und dann in das vorgesehene Feld schreibt? Wäre auch z.B. auch wenn ich eine Artikelnummer eingebe die ich zufällig auswendig kenne das dann automatisch die Bezeichnung im Bezeichnunsfeld steht?

[haentschman]

Moin...:P
Dein Problem ist nicht einfach zu erklären. Das muß man erstmal in Teilprobleme aufteilen:

1: Normalisierung sollte man kennen (1. Normalform) https://de.wikipedia.org/wiki/Normal...ng_(Datenbank) ... siehe Bilder, "Beziehungen" auf die Detailtabellen nur über ID!
2: Du mußt dich von der Optik in der GUI beim Datenbankdesign trennen! Die Daten werden/sollten via JOIN in der Query zusammengesetzt werden.

Zitat:

update war nicht erlaubt, wegen meiner Verknüpfungen bis auf die Kundentabelle mit der durfte ich weiterhin alles machen

...da hast du das erste Problem mit datensensitiven Controls. :? Datensätze die über einen JOIN abgrufen werden können nicht bearbeitet werden! Du mußt dich entscheiden. Entweder eine vernünftige Normalisierung oder datensensitive Controls. Beides geht nicht. :?
3: Tabellen erstellen mit jeweils einer ID Spalte mit dem PK drauf
Kunden,
Produkte
Einheiten
Zonen
4: Tabelle für die Positionen fehlt mit der ID für das Produkt
ID
AngebotsID // ID aus Angebote = Zuordnung zum Auftrag
ProduktID // ID des eigentlichen Produktes
Menge
5: Angebotstabelle:
ID // = pk
angebotsnummer
KundenID // ID aus der Kunden Tabelle statt kundennummer
ZonenID // ID aus der Zonentabelle
laufendenummer // gehört eigentlich in die Positionen? Oder?
bezeichnung // des Angebotes oder der Position?
// menge wird durch die Positionstabelle ersetzt
leistungsdatum
6: Daten laden in separaten Querys: Angebot, Positionen
7: Daten der Tabellen speichern in einer Transaktion

...wenn das so verstanden ist, dann gehts weiter mit FK usw.

Zitat:

Geht so etwas automatisch das wenn man in der Angebotstabelle z.B. unter Artikelbezeichnung einen Artikel eingibt, das in der Angebotstabelle automatisch beim E-Preis der Preis steht oder muss ich dann ein weiteres Query ausführen im Hintergrund welches mir den Preis zum Produkt ermittelt und dann in das vorgesehene Feld schreibt? Wäre auch z.B. auch wenn ich eine Artikelnummer eingebe die ich zufällig auswendig kenne das dann automatisch die Bezeichnung im Bezeichnunsfeld steht?

...später

:wink:

[stOrM]

Moin haentschman,
auch wenn das etwas durcheinander zu lesen ist, ich versuch das mal fix in Tabellen zu gießen nach deinem Vorbild und schmeiss am besten nachher mal ein Bild rein wie die Tabellen dann so aussehen....

Erstmal Danke dafür!

[stOrM]

So wie versprochen die angelegten Tabellen inkl. Feld Definitionen im Anhang

Zu Pos. 6 in deinem Beitrag meinst Du das?

Code:

SELECT
  *
FROM
  positionen
  INNER JOIN angebote ON positionen.angebotsID = angebote.angebotPK

[haentschman]

Ich muß dich trösten... ich muß außer Haus. Was ich beim Überfliegen gesehen paßt soweit...:P

[stOrM]

Zitat:

Zitat von haentschman (Beitrag 1371835)

Ich muß dich trösten... ich muß außer Haus. Was ich beim Überfliegen gesehen paßt soweit...:P

Kein Problem Du bist ja nicht mein persönlicher Problemlöser aber wäre schön wenn man sich später weiter damit befassen könnte, also mit den anderen Problemchen die ich damit noch habe...

[jobo]

Zitat:

Zitat von haentschman (Beitrag 1371819)

Datensätze die über einen JOIN abgrufen werden können nicht bearbeitet werden! Du mußt dich entscheiden. Entweder eine vernünftige Normalisierung oder datensensitive Controls. Beides geht nicht. :?

Das halte ich für falsch. Es ist eine Frage der Vorgehensweise, der verwendeten Datenbank sowie der Komponenten.
Vielleicht noch etwas gesunder Menschenverstand dazu und alles ist gut.

[p80286]

Dann erzähl mal was für ein Problem Du hast.

Zitat:

Zitat von stOrM (Beitrag 1371824)

Moin haentschman,
auch wenn das etwas durcheinander zu lesen ist,

Was an Haentschmans Beitrag war denn durcheinander?

Zitat:

Zitat von jobo (Beitrag 1371866)

Zitat:

Zitat von haentschman (Beitrag 1371819)

Datensätze die über einen JOIN abgrufen werden können nicht bearbeitet werden! Du mußt dich entscheiden. Entweder eine vernünftige Normalisierung oder datensensitive Controls. Beides geht nicht. :?

Das halte ich für falsch. Es ist eine Frage der Vorgehensweise, der verwendeten Datenbank sowie der Komponenten.
Vielleicht noch etwas gesunder Menschenverstand dazu und alles ist gut.

da mag ich Dir nicht pauschal wiedersprechen, aber das jetzt und hier zu diskutieren bringt stOrM erst einmal nicht weiter, denke ich.

Gruß
K-H

[stOrM]

Zitat:

Zitat von p80286 (Beitrag 1371882)

Dann erzähl mal was für ein Problem Du hast.

Zitat:

Zitat von stOrM (Beitrag 1371824)

Moin haentschman,
auch wenn das etwas durcheinander zu lesen ist,

Was an Haentschmans Beitrag war denn durcheinander?

Zitat:

Zitat von jobo (Beitrag 1371866)

Zitat:

Zitat von haentschman (Beitrag 1371819)

Datensätze die über einen JOIN abgrufen werden können nicht bearbeitet werden! Du mußt dich entscheiden. Entweder eine vernünftige Normalisierung oder datensensitive Controls. Beides geht nicht. :?

Das halte ich für falsch. Es ist eine Frage der Vorgehensweise, der verwendeten Datenbank sowie der Komponenten.
Vielleicht noch etwas gesunder Menschenverstand dazu und alles ist gut.

da mag ich Dir nicht pauschal wiedersprechen, aber das jetzt und hier zu diskutieren bringt stOrM erst einmal nicht weiter, denke ich.

Gruß
K-H

Na ja, dass Problem ist, ich glaube Heanschman hat seinen Beitrag editiert?
Weil jetzt tauchen neue Dinge auf, die wir vorhin nicht hatten...

1. laufendenummer // gehört eigentlich in die Positionen? Oder?
2. bezeichnung // des Angebotes oder der Position?

1. Hab ich abgeändert.
2. Gute Frage, ich müsste ja wissen wo das hingehört oder ob das weg kann. Denn laut Heanschman hat die Tabelle Positionen kein Feld Bezeichnung oder ich lese es falsch.

Dort steht ja:

Zitat:

4: Tabelle für die Positionen fehlt mit der ID für das Produkt
ID
AngebotsID // ID aus Angebote = Zuordnung zum Auftrag
ProduktID // ID des eigentlichen Produktes
Menge

[Olli73]

Mal eine weitere Frage: Wie willst du z.B. bei Preisänderungen reagieren? So wie dein Datenmodell jetzt ist, würde eine Preisänderung die alten Angebote verändern.

Lösungsmöglichkeiten:

- Du lässt eine Änderung der Artikel nicht zu. Ggf. muss dann der alte Artikel auf inaktiv (Statusfeld) gesetzt werden und ein neuer Artikel angelegt werden.

- Du rückst etwas von der Normalform ab und übernimmst Felder wie Preis, Artikelbezeichnung etc. mit in die Position (als "Kopie"). Da könnte man es (sofern gewünscht) sogar ermöglichen, dass der Nutzer einen individuellen Preis eintippt.

- Du machst noch eine Tabelle Preise mit Von-Datum, Bis-Datum, Preis.

[stOrM]

Zitat:

Zitat von Olli73 (Beitrag 1371892)

Mal eine weitere Frage: Wie willst du z.B. bei Preisänderungen reagieren? So wie dein Datenmodell jetzt ist, würde eine Preisänderung die alten Angebote verändern.

Lösungsmöglichkeiten:

- Du lässt eine Änderung der Artikel nicht zu. Ggf. muss dann der alte Artikel auf inaktiv (Statusfeld) gesetzt werden und ein neuer Artikel angelegt werden.

- Du rückst etwas von der Normalform ab und übernimmst Felder wie Preis, Artikelbezeichnung etc. mit in die Position (als "Kopie"). Da könnte man es (sofern gewünscht) sogar ermöglichen, dass der Nutzer einen individuellen Preis eintippt.

- Du machst noch eine Tabelle Preise mit Von-Datum, Bis-Datum, Preis.

Guter Einwand, aber Du siehst ja das ich komplett am Anfang stehe damit, deshalb könnte ich, selbst wenn ich wollte Dir deine Frage nicht beantworten.
Wir fangen ja erstmal an die Tabellen zu gestalten und die benötigten Felder in die richtigen Tabellen einzuordnen. Wenn es um spezifische Fragen geht bin ich da der falsche Ansprechpartner.

Aber ich denke auch, so wie Du geschrieben hast, dass ich Variante 1 nehmen würde jetzt so rein vom Gefühl her, also neuen Artikel anlegen, danke für die Anregung!

[Olli73]

Zitat:

Zitat von stOrM (Beitrag 1371899)

Guter Einwand, aber Du siehst ja das ich komplett am Anfang stehe damit, deshalb könnte ich, selbst wenn ich wollte Dir deine Frage nicht beantworten.
Wir fangen ja erstmal an die Tabellen zu gestalten und die benötigten Felder in die richtigen Tabellen einzuordnen. Wenn es um spezifische Fragen geht bin ich da der falsche Ansprechpartner.

Das musst/solltest du aber jetzt schon beim Datenbankdesign berücksichtigen, also welche Felder/Tabellen du dann dafür benötigst.

Version 1 würde ich (wenn überhaupt) nur nehmen, wenn sich die Preise fast nie ändern. Wenn du z.B. später wissen willst, wie oft sich ein Produkt verkauft, macht das die Abfrage deutlich schwieriger.

[stOrM]

Zitat:

Zitat von Olli73 (Beitrag 1371902)

Zitat:

Zitat von stOrM (Beitrag 1371899)

Guter Einwand, aber Du siehst ja das ich komplett am Anfang stehe damit, deshalb könnte ich, selbst wenn ich wollte Dir deine Frage nicht beantworten.
Wir fangen ja erstmal an die Tabellen zu gestalten und die benötigten Felder in die richtigen Tabellen einzuordnen. Wenn es um spezifische Fragen geht bin ich da der falsche Ansprechpartner.

Das musst/solltest du aber jetzt schon beim Datenbankdesign berücksichtigen, also welche Felder/Tabellen du dann dafür benötigst.

Version 1 würde ich (wenn überhaupt) nur nehmen, wenn sich die Preise fast nie ändern. Wenn du z.B. später wissen willst, wie oft sich ein Produkt verkauft, macht das die Abfrage deutlich schwieriger.

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.

[Olli73]

Zitat:

Zitat von stOrM (Beitrag 1371904)

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.

Also benötigst du entweder eine Tabelle Preise oder musst die Tabelle Positionen um die Felder Preis, Artikelbezeichnung etc. erweitern. Das kannst du ja jetzt in dein Datenmodell einbauen und dann können wir weitersehen was noch fehlt bzw. falsch ist.

Übrigens: Die Felder KundenPK und KundenId verwirren mich. Du solltest eine ID als PrimaryKey haben (das nennst du dann KundenPK oder KundenID) und ein Feld KundenNr.

[mikhal]

Ich habe da mal ein - bewusst flachgehaltenes - Datenmodell als Bild angehängt. Alle Tabellenfelder haben einen eindeutigen Präfix, macht später die Zuordnung in den Joins einfacher und auch die Identifizierung - woher kommt das Feld...

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.

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.

Insgesamt habe ich das Modell flach gehalten und nur die rudimentären Datenfelder erfasst.

Es ist ein Einstieg, bei weitem nicht perfekt und zur Diskussion gestellt. Das Script zur Generierung einer Firebird-Datenbank liegt bei...

Grüße
Mikhal

[stOrM]

Zitat:

Zitat von Olli73 (Beitrag 1371905)

Zitat:

Zitat von stOrM (Beitrag 1371904)

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.

Also benötigst du entweder eine Tabelle Preise oder musst die Tabelle Positionen um die Felder Preis, Artikelbezeichnung etc. erweitern. Das kannst du ja jetzt in dein Datenmodell einbauen und dann können wir weitersehen was noch fehlt bzw. falsch ist.

Übrigens: Die Felder KundenPK und KundenId verwirren mich. Du solltest eine ID als PrimaryKey haben (das nennst du dann KundenPK oder KundenID) und ein Feld KundenNr.

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?:oops:

Danke Mikhal,
dann warte ich jetzt erstmal bevor ich zum 10x alles umbaue, falls jemandem noch etwas dazu einfällt

Frage Mikhal,
ich hab mir mal das SQL Script angesehen...
Generatoren? Ich bin mir nicht sicher, aber so etwas gibt es nicht in MySql? Hab ich zumindest nicht gefunden ich glaub das geht nur über schräge Umwege....
Ich vermute mal das ich das dann über Delphi lösen müsste irgendwie...

[Olli73]

Zitat:

Zitat von stOrM (Beitrag 1371907)

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?:oops:

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.

[stOrM]

Zitat:

Zitat von Olli73 (Beitrag 1371910)

Zitat:

Zitat von stOrM (Beitrag 1371907)

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?:oops:

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:

Zitat von stOrM (Beitrag 1371904)

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:

Zitat von p80286 (Beitrag 1371922)

Zitat:

Zitat von stOrM (Beitrag 1371904)

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:

Zitat von stOrM (Beitrag 1371917)

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:

Zitat von Olli73 (Beitrag 1371926)

Zitat:

Zitat von stOrM (Beitrag 1371917)

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:

Zitat von Jumpy (Beitrag 1371930)

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...:P
Da sind ja gute Anworten dabei...:thumb:

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. 8-) Deshalb besser ProduktID...:wink:

[stOrM]

Zitat:

Zitat von haentschman (Beitrag 1371942)

Hallöle...:P
Da sind ja gute Anworten dabei...:thumb:

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. 8-) Deshalb besser ProduktID...:wink:

Ok, gebongt.
Ist das jetzt soweit durch oder anders, was ist mit dem Einwand, der korrekt ist bezüglich Handwerker Angebot bis zu einer gewissen Zeit gültig?
Was mach ich denn jetzt mit dem ganzen Tabellensalat...:shock:

Nur des Verständnisses wegen erstmal, warum haben einige Tabellen jetzt eigentlich doppelte Feldeinträge?
Also z.B. 2x EPreis usw? Muss das so?

[p80286]

Also ob man den "Primarykey" mit PK oder ID oder Key oder .. benennt ist egal(aber ID ist schon nicht schlecht), aber er sollte in einer Datenbank immer den gleichen Namen tragen.

Zitat:

Zitat von Jumpy (Beitrag 1371930)

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)

:thumb:
Solange er nur spielt, reichen ja auch allgemeine Hinweise. Soll es etwas konkretes werden, wäre zu überlegen ob z.b. eine Angebotspreistabelle und eine AuftragsPreistabelle notwendig wären. Und zuvor soll ein erstelltes Angebot in der DB verfügbar sein, oder reicht ein Ausdruck. Alleine dies würde das Design ja massiv beeinflussen.

Gruß
K-H

[stOrM]

Zitat:

Zitat von p80286 (Beitrag 1371944)

Also ob man den "Primarykey" mit PK oder ID oder Key oder .. benennt ist egal(aber ID ist schon nicht schlecht), aber er sollte in einer Datenbank immer den gleichen Namen tragen.

Zitat:

Zitat von Jumpy (Beitrag 1371930)

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)

:thumb:
Solange er nur spielt, reichen ja auch allgemeine Hinweise. Soll es etwas konkretes werden, wäre zu überlegen ob z.b. eine Angebotspreistabelle und eine AuftragsPreistabelle notwendig wären. Und zuvor soll ein erstelltes Angebot in der DB verfügbar sein, oder reicht ein Ausdruck. Alleine dies würde das Design ja massiv beeinflussen.

Gruß
K-H

Hmm gute Idee, wobei sich mir da jetzt unwissender Weise wieder die nächste Frage auftut.
Wenn ich ein Angebot einmal in der Tabelle habe, der Kunde sich irgendwann zum Zeitpunkt X entschliesst ok, machen wir. Würde es dann nicht reichen das Angebot so wie es dann vorliegt einfach in die Rechnungstabelle zu kopieren? Oder muss man das ganze dann direkt nochmals anlegen? also mit allen Tabellen und ggf noch weiteren?

[mikhal]

Angebotsgültigkeit ist ein Problem für sich: Hier reicht eigentlich ein Datumsfeld, um die Gültigkeit des Angebots zu prüfen.

Anders sieht es aus, wenn von einem Angebot verschiedene Versionen im Umlauf sind, wenn zum Beispiel das Angebot nachgebessert wird. Dann wird es richtig aufwändig. War hier aber nicht gefragt.

Stichwort Tabellensalat: Ich habe dir nicht umsonst ein sehr plattes, aber halbwegs normalisiertes Datenmodel geschickt. In der Grafik (die hier recht klein ausgefallen ist) sind die Beziehungen (Relationen) zwischen den Tabellen aufgezeichnet. Die helfen dir bei der Zuordnung der einzelnen Datenfelder.

@Haentschman: Grundsatz, den ich bereits vor 30 Jahren lernen musste: Eine Datenbanktabelle ohne Primary Key ist BÄH! JEDE Tabelle - und wenn sie noch so klein ist - muss einen PK haben! In meiner Notation ist das immer das Feld mit dem Namen ID (den Präfix spare ich mir mal).

Grüße
mikhal

[stOrM]

Zitat:

Zitat von mikhal (Beitrag 1371948)

Angebotsgültigkeit ist ein Problem für sich: Hier reicht eigentlich ein Datumsfeld, um die Gültigkeit des Angebots zu prüfen.

Anders sieht es aus, wenn von einem Angebot verschiedene Versionen im Umlauf sind, wenn zum Beispiel das Angebot nachgebessert wird. Dann wird es richtig aufwändig. War hier aber nicht gefragt.

Stichwort Tabellensalat: Ich habe dir nicht umsonst ein sehr plattes, aber halbwegs normalisiertes Datenmodel geschickt. In der Grafik (die hier recht klein ausgefallen ist) sind die Beziehungen (Relationen) zwischen den Tabellen aufgezeichnet. Die helfen dir bei der Zuordnung der einzelnen Datenfelder.

@Haentschman: Grundsatz, den ich bereits vor 30 Jahren lernen musste: Eine Datenbanktabelle ohne Primary Key ist BÄH! JEDE Tabelle - und wenn sie noch so klein ist - muss einen PK haben! In meiner Notation ist das immer das Feld mit dem Namen ID (den Präfix spare ich mir mal).

Grüße
mikhal

war auch sehr nett von Dir.
Das Problem ist, grad wenn man das zum ersten mal macht, hat jeder eine Idee (ist ja auch super) nur überfordert das oft (mich zumindest. Erst hatte ja Haetschman da mit mir angefangen an einer groben Struktur und dann kam dein tolles Model inkl. den Verknüpfungen nur an dem Schritt bin ich ja noch gar nicht, da ich nicht weiss warum A mit B und C mit F das muss ich erst mal kapieren.
Was mir noch aufgefallen ist bei Dir gibt es Generatoren? Ich glaube das kann ich in MySQL wohl vergessen oder über Umwege?

[p80286]

Zitat:

Zitat von stOrM (Beitrag 1371950)

Das Problem ist, grad wenn man das zum ersten mal macht, hat jeder eine Idee (ist ja auch super) nur überfordert das oft (mich zumindest. Erst hatte ja Haetschman da mit mir angefangen an einer groben Struktur und dann kam dein tolles Model inkl. den Verknüpfungen nur an dem Schritt bin ich ja noch gar nicht, da ich nicht weiss warum A mit B und C mit F das muss ich erst mal kapieren.

Zitat:

Zitat von stOrM (Beitrag 1371950)

Was mir noch aufgefallen ist bei Dir gibt es Generatoren? Ich glaube das kann ich in MySQL wohl vergessen oder über Umwege?

Falls das erste Zitat stimmt, dann ist das vollkommen unerheblich, da Du nicht sooo viele Vorkenntnisse hast.
Was an Mikhals Vorschlag verstehst Du nicht?

Gruß
K-H

[jobo]

Zitat:

Zitat von stOrM (Beitrag 1371950)

Was mir noch aufgefallen ist bei Dir gibt es Generatoren? Ich glaube das kann ich in MySQL wohl vergessen oder über Umwege?

Das spielt für ein logisches Modell keine Rolle, ein physisches (Berücksichtigung des konkreten RDBMS) muss das dann entsprechend adaptieren. In mysql wahrscheinlich autoincrement Felder. Tja und wo wir gerade beim Thema sind, wenn Du (noch) die Wahl hast, empfehle ich als Alternative zu mySQL Firebird oder Postgres. Beide können Geneneratoren/Sequenzen (und natürlich mehr, weswegen ich sie empfehle)

[stOrM]

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.

[jobo]

mal auf die Schnelle zu Deinen ersten beiden Punkten.

Du würdest nicht solche (riesigen) Joins bauen und das Ergebnis editieren.
Solche ein Select wie unter (1) würdest Du ggf in einem Report benötigen, vermutlich nicht mal da.

Wenn Du Adressen erfasst (Eingabe), hast Du ein query für die Adresstabelle. Wenn es ein Artikel ist, dann ein Query für die Artikel usw.
Verbindungen wie Du sie im Selectstatement oben später nutzt, stellst Du bei der Eingabe bspw. durch DBLookupcombobox her oder durch die Nutzung von Master Detail Properties in Datasets.

Damit würde ich jedenfalls anfangen. Eins nach dem anderen. Erfassung von Kunden, Kundenadressn, Artikeln usw., alles nach dem gleichen Muster.
Wenn das läuft und das Vorgehen / Implementierung klar ist, kannst Du komplexere Eingabemasken in Angriff nehmen, z.B. gemeinsame Erfassung von Kunde und Hauptanschrift. Usw. usf.

Wichtig ist erstmal, dass Du alles sauber rein und raus bekommst (und bei Bedarf reporten kannst> hier sind dann je nachdem größere Joins notwendig, mit einem guten Reportdesigner aber auch nicht so sehr)

Vergessen: Berechnung von Preisen etc. , Dein Ansatz ist ok, man kann hier und an anderen Stellen über die Nutzung von Views nachdenken. Das sind sozuagen benannte select Statement, mit denen man immer wieder kehrende Aufgaben (Darstellungen) sauber abbilden kann.

[mikhal]

Deine Fragen 1 und 2 hat Jobo ja bereits beantwortet. Hier meine Antworten zu den folgenden Fragen:

Zu 3): Natürlich kannst du die PLZ als zusätzliches Feld aufnehmen, genauso wie die Straße, den Ort etc. Dazu benötigst du keine zusätzliche Tabelle für die PLZ, es sei denn, du möchtest dir das Eintippen des Ortes sparen, dann benötigst du eine Tabelle mit der PLZ und dem Ortsnamen. Dann kannst du nachdem die PLZ in dieser Tabelle gefunden wurde, den Ortsnamen automatisch ziehen. Referenzieren musst du dann den PK der Postleitzahlen-Tabelle in deinem Anschriftendatensatz: PK in PLZ-Tabelle PLZ_ID Integer, zusätzliches Feld ANS_PLZ_ID Integer als FK (Fremdschlüssel oder Foreign Key).

zu 4): Kannst du so machen, ich hätte es aber als Produkt geführt, damit ich die Preisfindung leichter realisieren kann (Stichwort: Gültigkeitszeitraum). Aufwendig wird bei der Nutzung einer Zonentabelle die Zuordnung in der Angebotsposition, hier gibt es in meinem Datenmodell keine Referenz zu einer Zonentabelle, musst du dann ergänzen. ACHTUNG: Dann bekommst du ein Problem mit dem Artikel, denn der FK ANG_ART_ID ist im Modell NOT NULL definiert, muss also gefüllt werden! Dein Ansatz die Zone beim Kunden zu hinterlegen ist nicht falsch, dann solltest du aber tatsächlich eine Funktion schreiben, die aus dieser Zoneninformation einen Dummy-Artikel im Angebot generiert (der muss im Produktstamm angelegt sein), der über die Preistabelle der Produkte den richtigen Preis im Angebot aufführt.

zu 5): Richtig, das Datum bezieht sich auf das Erfassungsdatum, wenn du im Programm oder einer Hilfstabelle einen festen Zeitraum für die Gültigkeit eines Angebots festlegst, kannst du das Enddatum berechnen. Du solltest aber ein weiteres Datenfeld in der Tabelle aufnehmen, dass dieses errechnete Datum aufnimmt. Sollte sich später einmal dieser vorgegebene Zeitraum ändern, wirst du falsche Daten berechnen.

zu 6): Richtig

zu 7): Ja, ich habe es mir hier einfach gemacht. Ich schrieb ja bereits, dass dieses Modell flach und einfach gehalten ist.

Grüße Mikhal

[p80286]

Zitat:

Zitat von stOrM (Beitrag 1372065)

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.

Du hast eine "Kundentabelle"und eine "Anschrifttabelle".
in der Anschrifttabelle gibt es
AnschriftID
KundenID
Anschrifttyp
Strasse,Ort,plz (usw. was man so braucht)

in Anschrifttyp kommt dann die 1,2,3,4..x hinein, über die definiert wird was für ein Typ (Rechnungsadresse, Lieferadresse, primäre Adresse...) das ist.

Wenn Du jetzt an einen Kunden liefern willst, dann kommt auf den Lieferschein die Lieferadresse und auf die zu erstellende Rechnung die Rechnungsadresse. Soweit ist das ja wohl einsichtig.

SQL-Code:

select Name,strasse,plz,ort from kundentable join adresstable on (kundentavle.kundenID=adresstable.kundenID and adresstable.adresstyp=x)

Interessant wird es wenn Du keine Lieferadresse erfasst hast. Dann könntest Du
a) davon ausgehen, das das dem Büro schon auffällt und die entsprechenden Korrekturen durchgeführt werden.
b) eine Fehlermeldung ausgeben
c) falls die Lieferadresse,Rechnungsadresse.... fehlt, die primäre Adresse ausgeben
d) es garnicht dazu kommen lassen, da immer alle Adressen erfasst werden müssen und sei es durch ein automatisches klonen der Daten
e) da der adresstyp auch eine Wertigkeit beinhaltet, bei der Suche nach einer Adresse, sollte diese nicht vorhanden sein, Du die höherwertige Adresse ausgibst.

und da gibt es bestimmt noch ein paar Winkelzüge um das noch verwirrender zu gestalten.
Des weiteren kann man natürlich auch die Adressen mit einem Gültigkeitsdatum, bzw einem Zeitraum versehen.
Langer Rede kurzer Sinn, neben den Daten für die DB-Struktur KundenID,AdressID und den nackten Nutzdaten Strasse,PLZ,Ort (Gebäude no??) benötigst Du noch interne Verwaltungsdaten Startdatum,Endedatum,Adresstyp usw.

Wichtig hierfür ist, daß Du weißt welche Arbeitsabläufe Du mit welchen Daten du abbilden willst.

Gruß
K-H

[jobo]

Noch ein paar Anmerkungen:

zu 4)
Die Zonen müssen sich bei einem Datenmodell mit möglichen Mehrfachadressen nicht auf den Kunden, sondern auf die Adressen, bzw. die jeweils verwendete Lieferadresse beziehen bzw dort eingetragen werden. Genau genommen spielt sogar das Auslieferungslager mit rein, wenn es mehrere gibt.
Wenn Du nichts besseres zu tun hast, kannst Du auch gleich mit Entfernungstabellen arbeiten.

zu 7.
Wurde ja schon erklärt. Grundsätzlich ist eine Nachschlagetabelle technisch nichts anderes als andere Tabellen. Sie hat keinen anderen Zweck als einen symbolischen Zahlwert durch Klartext zu ersetzen, spart etwas Platz und spart bei interner Verwendung des Symbolwertes Rechenleistung.
Der Nachschlagewert kann dann wiederum bei Bedarf übersetzt werden, geändert werden .. etc ohne dass man an der Verarbeitungslogik justieren muss. Diese Mechaniken baut man nach Bedarf auf, jeder hat da so seine Steckenpferde.
Nachschlage können untereinander wiederum klassifiziert werden, Priorisierungen, Sortierungen, je nachdem worum es geht.
Aber lieber klein anfangen. Ein Nachschlagetyp kommt im Zweifel auch ohne Nachschlagetabelle aus. Kann man alles nach und nach erweitern.

[stOrM]

@p80286 Danke für die weitere Ausführung, du kannst einem echt Mut machen :-D

@Jobo, Danke Dir werd ich berücksichtigen.

@Mikhal
Du schriebst davon, dass sich der Ort dann automatisch ziehen lässt, dass hab ich entweder nicht richtig verstanden oder ich hab hier einen Fehler gemacht.
Ich habe in der Anschriften Tabelle zwei weitere Felder angelegt:

AN_PLZ, Typ Integer(5)
AN_ORT Typ Varchar

Dann habe ich eine Postleitzahlentabelle erstellt mit den Feldern:

PL_VORWAHL, Typ Integer
PL_PLZ, Int(5)
PL_ORT, Typ Varchar
PL_BUNDESLAND, Typ Varchar

In der Anschriften Tabelle den FK (FK_AN_PLZ) angelegt und so verknüpft:

AN_PLZ = PL_PLZ

Wenn ich jetzt eine Postleitzahl in der Anschriftentabelle eintrage wird der Ort aber dort nicht automatisch eingetragen (ich denke mal entweder habe ich deinen Satz komplett missverstanden oder einen Fehler gemacht)

Ich habe mir zwei Sachen dazu überlegt, für den Fall, dass ich es falsch verstanden habe, ich könnte über einen JOIN mit dem Parameter PLZ den Ort aus der Postleitzahlentabelle holen und dann in die Anschriften Tabelle schreiben. Ginge ja auch notfalls, oder z.B. über einen After Insert Trigger wäre das glaube ich ja auch möglich?

[hstreicher]

es gibt hier einen großen Denkfehler bzgl der Postleitzahlen:
Eine Postleitzahl kann durchaus mehrere Orte umfassen

http://www.gutefrage.net/frage/eine-...eine-bestimmte

mfg Hannes