Wieder mal die Tabellenstrukturen

[jobo]

Zitat von haentschman:

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 von stOrM:

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

Was an Haentschmans Beitrag war denn durcheinander?

Zitat von jobo:

Zitat von haentschman:

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 von p80286:

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

Zitat von stOrM:

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

Was an Haentschmans Beitrag war denn durcheinander?

Zitat von jobo:

Zitat von haentschman:

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 von 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.

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 von stOrM:

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 von Olli73:

Zitat von stOrM:

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.