Abfrage, ob ein Produkt gültig ist²

[Twilo]

Hallo,

ich habe immer noch mein Problem, dass ich herausfinden möchte, ob ein Produkt gültig ist

Datenbanklayoutdatei für den DBdesigner4
SQL Statement um die Tabellen und die Testdaten zu erstellen
zur Verfügung steht im Moment Apache 1.3.37, PHP 5.1.5(cgi) und MySQL 4.1.21

das Produkt test1 darf nicht auftauchen, da

• die Auflage nur die Lieferzeiten 2 und 3 haben
• die Farben nur die Lieferzeit 1
• die anderen Optionen die Lieferzeiten 1 und 2
• das Produkt selber hat die Lieferzeiten 1, 2 und 3
  --- die Lieferzeit 1, 2 und 3 taucht bei allen Optionen nicht gleichzeitig auf

hätte eine Farbe die Lieferzeiten ID 2, wäre das Produkt gültig
wenn ein Produkt eine Option nicht hat, darf es nicht mehr angezeigt werden

ps. vielleicht hat jemand ja ein Tipp zum Datenbanklayout :)

die Lieferzeiten sollen für ein Produkt und den Optionen separat einstellbar sein, bei den Farben macht es zwar kein Sinn, soll aber im Moment so umgesetzt werden
ein Produkt kann mehrere Optionen haben

kann man das Datenbanklayout so abändern, dass man eine neue Option, z.B. Falzen, etc. hinzufügen kann, ohne dass man am Datenbanklayout etwas ändern muss?
Im Moment muss ich für jede weitere Option das Datenbanklayout ändern

mfg
Twilo

[Ilja]

yo,

sorry, ich konnte mich letzes mal nicht melden, hatte ein wenig viel um die ohren.

kurz noch mal zu datenlayout. was die lieferzeiten betrifft, so würde ich grundsätzlich nur die schnellst-mögliche lieferzeit festhalten, wenn man damit implizieren kann, dass die langsameren lieferzeiten auch möglich sind. das spart schon mal mindestens eine tabelle, da es sich von einer 1:n in eine 1:1 beziehung wandelt.

es wäre auch schöner, mal eine grafische übersicht vom daten-layout zu sehen, hilft ungemein es zu analysieren.

was die abfrage betrifft, so ist die frage, bist du den grundsätzlich bereit, das daten-design zu ändern oder soll es erst einmal so bleiben. falls es sich nämlich ändert, dann ändert sich auch die abfrage.

kann man das Datenbanklayout so abändern, dass man eine neue Option, z.B. Falzen, etc. hinzufügen kann, ohne dass man am Datenbanklayout etwas ändern muss?

bestimmt, aber ich würde vorher gerne mal eine grafische umsetzung des daten-designs sehen, ist sonst viel mehr arbeit, das aus den tabellen-definitionen herzuleiten.

Ilja

[Twilo]

Hallo,

sorry, ich konnte mich letzes mal nicht melden, hatte ein wenig viel um die ohren.

nachdem du eine längere Zeit nicht im Forum warst, war ich am überlegen dir eine eMail zu schreiben. Ich hab sie jedoch nicht geschrieben, da ich nicht wusste, ob es dich stören würde ;)

kurz noch mal zu datenlayout. was die lieferzeiten betrifft, so würde ich grundsätzlich nur die schnellst-mögliche lieferzeit festhalten, wenn man damit implizieren kann, dass die langsameren lieferzeiten auch möglich sind. das spart schon mal mindestens eine tabelle, da es sich von einer 1:n in eine 1:1 beziehung wandelt.

wenn man nur nach der langsamsten Lieferzeit abfragt, müsste man dafür sorgen, dass die auch immer zur Verfügung steht, wenn eine schnellere ausgewählt wird
Die Lieferzeiten kann man per Webinterface hinzufügen, das Datenbankscript kann im Moment nicht ermitteln, welches die langsamste Lieferzeit ist

es wäre auch schöner, mal eine grafische übersicht vom daten-layout zu sehen, hilft ungemein es zu analysieren.

wie meinst du das mit grafischer?
ich kann mir darunter im Moment nichts vorstellen

was die abfrage betrifft, so ist die frage, bist du den grundsätzlich bereit, das daten-design zu ändern oder soll es erst einmal so bleiben. falls es sich nämlich ändert, dann ändert sich auch die abfrage.

für Verbesserungen bin ich immer zu haben
die vorhandenen Scripte kann man sicherlich ohne Probleme anpassen :-)

kann man das Datenbanklayout so abändern, dass man eine neue Option, z.B. Falzen, etc. hinzufügen kann, ohne dass man am Datenbanklayout etwas ändern muss?

bestimmt, aber ich würde vorher gerne mal eine grafische umsetzung des daten-designs sehen, ist sonst viel mehr arbeit, das aus den tabellen-definitionen herzuleiten.

wenn ich weiß, was du damit meinst, kann ich dir soetwas anfertigen

mfg
Twilo

[Ilja]

yo,

wie meinst du das mit grafischer?
ich kann mir darunter im Moment nichts vorstellen

zum Beispiel ein E/R Modell deiner Datenbank. Access kann so was per knopfdruck, eine grafische Übersicht des Designs erstellen. Das hilft ungemein, deinen Ansazt zu verstehen und nach Verbesserungen Aussschau zu halten.

Ilja

[Twilo]

Hallo,

wie meinst du das mit grafischer?
ich kann mir darunter im Moment nichts vorstellen

zum Beispiel ein E/R Modell deiner Datenbank. Access kann so was per knopfdruck, eine grafische Übersicht des Designs erstellen. Das hilft ungemein, deinen Ansazt zu verstehen und nach Verbesserungen Aussschau zu halten.

Access habe ich leider nicht zur Verfügung

reicht dafür nicht die sql Datei für den DBDesigner4?
hier ist das DatenbankLayout mal als PNG exportiert

mfg
Twilo

[Ilja]

yo,

mir fallen spontan zwei möglichkeiten ein. zum einen kannst du dir eine menge tabellen sparen, indem du zwei entitäten bildest:

1. produkte
2. eigenschaften

in der ersten tabelle stehen natürlich die produkte, in der zweiten die eigenschaften (nicht inhalte), die ein produkt haben kann. das wären also zum beispiel farbe, gewicht, versandart, auflage etc. zwischen den beiden entiäten besteht eine n:m beziehung, sprich es braucht eine zusätzliche beziehungstabelle:

3. produkte_eigenschaften

die spalten wären:

produkt_id
eigenschaft_id
lieferzeit
wert

wobei die ersten zwei spalten einen zusammengesetzten primär-schlüssel bilden. bei lieferzeit wird immer nur die schnellstmögliche lieferzeit abgebildet, die langsameren werden impliziert. der vorteil davon ist zum einen wesentlich weniger tabellen und somit übersichtlicher. auch wenn neue eigenschaften hinzukommen, kann man dies tun, ohne in das daten-layout eingreifen zu müssen. der nachteil besteht darin, dass du die einzelnen eigenschaften wie zum beispiel der farbe nicht verschiedene attribute zuordnen kannst, die nur spezifisch für die farbe sind, da ja sonst alle anderen eigenschaften davon mitbetroffen wären. falls solche individuelle attribute der jweiligen eigenschaften auszuschließen sind, ist dies ein sehr guter weg.

falls du aber lieber für jede eigenschaft eine einzelne entität machen willst, damit du ihnen individuelle attribute zuordnen kannst, dann ist meine frage, ob die lieferzeiten nicht auch von dem produkt abhängt oder nur von der eigenschaft bestimmt wird ?
beispiel farbe, ist dabei die lieferzeit nicht auch davon abhängig, welches produkt hergestellt wird oder bezieht sich die lieferzeit nur so wie du es gemacht hast auf die farbe, sprich ist unabhängig von dem produkt ?

wenn die lieferzeit nämlich auch von dem produkt abhängig ist, dann würde die lieferzeit mit in die beziehungstabelle kommen von farbe und produkte. das wäre wichtig erst einmal abzuklären.

Ilja

[Ilja]

yo,

kleine korrektur, war ja gestern schon spät. ;-)

der zusammengestzte schlüssel der beziehungstabelle bei dem ersten ansatz muss natürlich aus drei spalten bestehen, nämlich den beiden fremdschlüsseln und der spalte wert, da ja ein produkt unterschiedliche farben haben kann. wenn dir es nicht reicht, nur die schnellste lieferzeit in der datenbank anzugeben, dann nimmst du zusätzlich noch die lieferzeit in den pk mit rein.

Ilja

[Twilo]

Hallo,

kleine korrektur, war ja gestern schon spät. ;-)

der zusammengestzte schlüssel der beziehungstabelle bei dem ersten ansatz muss natürlich aus drei spalten bestehen, nämlich den beiden fremdschlüsseln und der spalte wert, da ja ein produkt unterschiedliche farben haben kann. wenn dir es nicht reicht, nur die schnellste lieferzeit in der datenbank anzugeben, dann nimmst du zusätzlich noch die lieferzeit in den pk mit rein.

ich entwerfe gerade ein Entwurf, ich werde mich demnächst melden :-)
nur die schnellste Lieferzeit wäre zwar möglich, jedoch Kundenunfreundlich, da die schnellste auch die teurerste ist ;-)

mfg
Twilo

[Ilja]

yo,

nur die schnellste Lieferzeit wäre zwar möglich, jedoch Kundenunfreundlich, da die schnellste auch die teurerste ist ;-)

um gottes willen, dass eine hat doch mit den anderen nichts zu tun. nur weil man nur die schnellste möglichkeit speicherst, heißt es doch nicht auch, dass der kunde auch nur diese zur auswahl bekommt. letztlich soll es so sein, dass der kunde alle lieferzeiten bekommt, bis zu schnellst-möglichen lieferzeit und diese ist in der datenbank gespeichert !

Ilja

[Twilo]

Hallo,

nur die schnellste Lieferzeit wäre zwar möglich, jedoch Kundenunfreundlich, da die schnellste auch die teurerste ist ;-)

um gottes willen, dass eine hat doch mit den anderen nichts zu tun. nur weil man nur die schnellste möglichkeit speicherst, heißt es doch nicht auch, dass der kunde auch nur diese zur auswahl bekommt. letztlich soll es so sein, dass der kunde alle lieferzeiten bekommt, bis zu schnellst-möglichen lieferzeit und diese ist in der datenbank gespeichert !

bekomm ich dann nicht Probleme, wenn die schnellste Lieferzeit gelöscht wird?
z.B.
1 express
2 normal
3 overnight
4 in 3 Stunden
5 extrem langsam ;)

was wird dann in den Datensatz, wo die 3 eingetragen wurde, wenn "overnight" aus welchen Grund auch immer gelöscht wird?

1 (express) dauert länger
2 (normal) dauert noch länger
3 (overnight) soll gelöscht werden
4 (in 3 Stunden) kann zu schnell sein
5 (extrem langsam) naja ;)

man müßte dann ja irgendwie abspeichern, welche Lieferzeit die schnellste ist.

ist soweit mein Gedankengang richtig?

mfg
Twilo

[Ilja]

yo,

bekomm ich dann nicht Probleme, wenn die schnellste Lieferzeit gelöscht wird?

das ist das thema der referentiellen integrität, dass genau das absichert, dass du datensätze nicht einfach löschen kannst, die noch bezug als fremdschlüssel auf diesen datensatz nehmen. klar, wenn man irgendwann einmal ein lieferzeit löschen will, muss man vorher alle detensätze, die sich auf diesen beziehen, auf einen neuen verändern oder aber eben mitlöschen. beides sind möglichkeiten, die auch so in der praxis genutzt werden.

das ist aber eine grundsätzliche problematik und hat wenig mit dem daten-design zu tun, sondern dass tabellen (relationen) untereinander in beziehung (relationships) stehen undman eben nicht so einfach "löcher in die datenbank schießen" kann.

Ilja

[Twilo]

Hallo,

bekomm ich dann nicht Probleme, wenn die schnellste Lieferzeit gelöscht wird?

das ist das thema der referentiellen integrität, dass genau das absichert, dass du datensätze nicht einfach löschen kannst, die noch bezug als fremdschlüssel auf diesen datensatz nehmen. klar, wenn man irgendwann einmal ein lieferzeit löschen will, muss man vorher alle detensätze, die sich auf diesen beziehen, auf einen neuen verändern oder aber eben mitlöschen. beides sind möglichkeiten, die auch so in der praxis genutzt werden.

das ist aber eine grundsätzliche problematik und hat wenig mit dem daten-design zu tun, sondern dass tabellen (relationen) untereinander in beziehung (relationships) stehen undman eben nicht so einfach "löcher in die datenbank schießen" kann.

ok, ich werde mein Datenbankentwurf noch etwas verfeinern ;-)

mfg
Twilo

[Twilo]

Hallo,

mir fallen spontan zwei möglichkeiten ein. zum einen kannst du dir eine menge tabellen sparen, indem du zwei entitäten bildest:

1. produkte
2. eigenschaften

in der ersten tabelle stehen natürlich die produkte, in der zweiten die eigenschaften (nicht inhalte), die ein produkt haben kann. das wären also zum beispiel farbe, gewicht, versandart, auflage etc. zwischen den beiden entiäten besteht eine n:m beziehung, sprich es braucht eine zusätzliche beziehungstabelle:

3. produkte_eigenschaften

die spalten wären:

produkt_id
eigenschaft_id
lieferzeit
wert

wobei die ersten zwei spalten einen zusammengesetzten primär-schlüssel bilden. bei lieferzeit wird immer nur die schnellstmögliche lieferzeit abgebildet, die langsameren werden impliziert. der vorteil davon ist zum einen wesentlich weniger tabellen und somit übersichtlicher. auch wenn neue eigenschaften hinzukommen, kann man dies tun, ohne in das daten-layout eingreifen zu müssen. der nachteil besteht darin, dass du die einzelnen eigenschaften wie zum beispiel der farbe nicht verschiedene attribute zuordnen kannst, die nur spezifisch für die farbe sind, da ja sonst alle anderen eigenschaften davon mitbetroffen wären. falls solche individuelle attribute der jweiligen eigenschaften auszuschließen sind, ist dies ein sehr guter weg.

Tabellen einparen hören sich immer gut an ;-)

Frage:
bekomm ich dann nicht Probleme mit meiner Formel, die ein Preis ausrechnet?

SELECT ROUND((  
(groesse._breite / 1000 * groesse._hoehe / 1000* auflage._auflage * gewicht._bedrgewicht/1000 * gewicht._bedrkosten) +  
((farbe._vorderfarbe + farbe._rueckfarbe) * produkt._plattenkosten) +  
((((farbe._vorderfarbe + farbe._rueckfarbe) * produkt._ruestzeitproplatte/60) + ((auflage._auflage / CEIL(produkt._bogengroesse / (groesse._breite / 1000 * groesse._hoehe / 1000 * 1.1))) / produkt._maschinengeschwindigkeit) + produkt._einrichtzeit/60) * produkt._maschinenstundensatz) +  
(produkt._bogengroesse * gewicht._bedrgewicht/1000 * gewicht._bedrkosten * produkt._einrichtboegen) +  
ceil(groesse._breite / 1000 * groesse._hoehe / 1000 * auflage._auflage * gewicht._bedrgewicht/1000) * versandart._versdandt) *  
faktor._faktor*ffracht._faktor, 2) AS preis  
FROM `t1_produkt` AS produkt  
INNER JOIN t1_gewinnfaktor AS faktor ON faktor._gewinnfaktor_id = produkt._gewinnfaktor_id  
INNER JOIN t1_produkt_has_farbe ON t1_produkt_has_farbe._produkt_id = produkt._produkt_id  
INNER JOIN t1_farbe AS farbe ON farbe._farb_id = t1_produkt_has_farbe._farb_id  
INNER JOIN t1_produkt_has_versandart ON t1_produkt_has_versandart._produkt_id = produkt._produkt_id  
INNER JOIN t1_versandart AS versandart ON versandart._versandart_id = t1_produkt_has_versandart._versandart_id  
INNER JOIN t1_produkt_has_auflage ON t1_produkt_has_auflage._produkt_id = produkt._produkt_id  
INNER JOIN t1_auflage AS auflage ON auflage._auflage_id = t1_produkt_has_auflage._auflage_id  
INNER JOIN t1_produkt_has_gewicht ON t1_produkt_has_gewicht._produkt_id = produkt._produkt_id  
INNER JOIN t1_gewicht AS gewicht ON gewicht._gewicht_id = t1_produkt_has_gewicht._gewicht_id  
INNER JOIN t1_produkt_has_groesse ON t1_produkt_has_groesse._produkt_id = produkt._produkt_id  
INNER JOIN t1_groesse AS groesse ON groesse._groesse_id = t1_produkt_has_groesse._groesse_id  
  
INNER JOIN t1_fracht AS ffracht ON ffracht._fracht_id = fprodukt._fracht_id  
INNER JOIN t1_fracht_has_produkt AS fprodukt ON fprodukt._fracht_id = ffracht._fracht_id  
INNER JOIN t1_fracht_has_farbe AS ffarbe ON ffarbe._fracht_id = ffracht._fracht_id  
INNER JOIN t1_fracht_has_gewicht AS fgewicht ON fgewicht._fracht_id = ffracht._fracht_id  
INNER JOIN t1_fracht_has_groesse AS fgroesse ON fgroesse._fracht_id = ffracht._fracht_id  
INNER JOIN t1_fracht_has_auflage AS fauflage ON fauflage._fracht_id = ffracht._fracht_id  
INNER JOIN t1_fracht_has_versandart AS fversandart ON fversandart._fracht_id = ffracht._fracht_id  
WHERE produkt._produkt_id = %d AND gewicht._gewicht_id = %d AND groesse._groesse_id = %d AND farbe._farb_id = %d AND auflage._auflage_id = %d AND versandart._versandart_id = %d AND fprodukt._produkt_id = %d AND fgewicht._gewicht_id = %d AND fgroesse._groesse_id = %d AND ffarbe._farb_id = %d AND fauflage._auflage_id = %d AND fversandart._versandart_id = %d ORDER BY ffracht._prioritaet

wenn sich bei einer Option oder bei ein Produkt ein Wert ändert, wird ein neuer aus den neuen Daten erstellt und der alte als inaktiv markiert, damit ich den alten Preis für ein bestehenden Auftrag berechnen kann.
Im alten Datensatz wird ein vermerk gemacht, welcher der aktuelle Datensatz ist, damit wenn der Kunde das Produkt noch einmal bestellen möchte, dass man ihn darauf hinweisen kann, dass sich etwas am Preis geändert hat

wenn ich richtig überlege, würde ich ja Probleme bekommen, wenn jemand eine Option z.B. Farben löschen würde. Die Formel würde ja noch versuchen auf diese Teile zuzugreifen

was natürlich der Vorteil ist, dass man relativ leicht neue Optionen hinzufügen kabnn, z.B. Falzen, etc., was noch kommen wird

falls du aber lieber für jede eigenschaft eine einzelne entität machen willst, damit du ihnen individuelle attribute zuordnen kannst, dann ist meine frage, ob die lieferzeiten nicht auch von dem produkt abhängt oder nur von der eigenschaft bestimmt wird ?

die Lieferzeit hängt von allen Option und vom Produkt ab
Beispiel: es gibt eine Option, z.B. eine bestimmtes Papiergewicht, oder der Kunde möchte eine Auflage von z.B. 1000000 Stück, soetwas ist natürlich über Nacht nicht realisierbar
der Kunde soll die Möglichkeit haben zwischen den verschiedenen Lieferzeiten auswählen zu können, da diese sich preislich unterscheiden

beispiel farbe, ist dabei die lieferzeit nicht auch davon abhängig, welches produkt hergestellt wird oder bezieht sich die lieferzeit nur so wie du es gemacht hast auf die farbe, sprich ist unabhängig von dem produkt ?

die Lieferzeit bezieht sich doch auf jede Option und auf das Produkt selber
t1_farbe_has_t1_lieferzeit
t1_versandart_has_t1_lieferzeit
t1_produkt_has_t1_lieferzeit
t1_auflage_has_t1_lieferzeit
t1_gewicht_has_t1_lieferzeit
t1_groesse_has_t1_lieferzeit

wenn die lieferzeit nämlich auch von dem produkt abhängig ist, dann würde die lieferzeit mit in die beziehungstabelle kommen von farbe und produkte. das wäre wichtig erst einmal abzuklären.

die Lieferzeit muss von jeder Option und von jeden Produkt abhängen, da es vielleicht nich über Nacht lieferbar ist.

hier ist mal ein kleiner Entwurf
Datenbanklayoutdatei für den DBdesigner4
DatenbankLayout

von den Tabellen her gefällt es mir viel besser
nur wie setze ich das mit meinen Formeln um?

ein Produkt verwendet eine spezielle Formel
im Moment habe ich eine Tabelle "Formel", wo die Formel drin steht, in der Produkttabelle ist eine Spalte FormelID, die ich vorher abfrage um die richtige Formnel zu ermitteln. Anhand dieser Formel wird dann der Preis berechnet

mfg
Twilo

[Twilo]

Hallo,

ich habe das Datenbankmodell noch einmal geändert
Datenbanklayoutdatei für den DBdesigner4
DatenbankLayout

im Moment hab ich ein Knoten im Kopf ;-)
ich weiß nicht, wie ich die Formel umschreiben kann/muss

mfg
Twilo

[Ilja]

yo,

bekomm ich dann nicht Probleme mit meiner Formel, die ein Preis ausrechnet?

ändert sich das daten-design, ändern sich in aller regel auch alle abfragen und berechnungen. man muss sich nur bewußt sein, dass jedes design vor und nachteile hat und selten es das "perfekte" layout für alle fälle gibt. wichtig ist nur, dass man alle relevanten daten und beziehungen erfasst.

wenn sich bei einer Option oder bei ein Produkt ein Wert ändert, wird ein neuer aus den neuen Daten erstellt und der alte als inaktiv markiert, damit ich den alten Preis für ein bestehenden Auftrag berechnen kann.

ok, das ist eine neue erkenntnis. grundsätzlich sind datenbanken dafür konzepiert, die gegenwart einer entsprechenden umgebung widerzugeben. will man daten der vergangenheit mit ins spiel bringen, dann muss man ein paar besonderheiten beachten. fremdschlüssel, bzw. beziehungen können sich in punkto vergangenheit als hinderniss erweisen. stell dir eine kundentabelle vor und die zugehörige rechnung des kunden. ändert sich nun die adresse oder sogar der name des kunden und der verweis auf der rechnung wäre auf die kundentabelle, wäre das ein widerspruch, da die datenbank nur aktuelle daten enthält, nicht aber die vergangenheit. deswegen sollte man in rechung besser keine verweise auf andere tabellen haben, wenn diese sich ändern können, also direkt in der tabelle für rechnungen auch die damals aktuelle adresse, namen, etc. speichern. es handelt sich hierbei auch um keine redundanz, da diese daten sich ja eben nicht mitändern sollen, also unabhängig sind. das thema vergangenheit und datenbanken ist also recht komplex, man muss sich das bewußt machen, wie genau man die vergangeheit festhalten will.

wenn ich richtig überlege, würde ich ja Probleme bekommen, wenn jemand eine Option z.B. Farben löschen würde. Die Formel würde ja noch versuchen auf diese Teile zuzugreifen

sicherlich, das sind fälle, die man abdecken muss. ich würde wie gesagt vergangene dinge nicht durch beziehungen der gegenwart abhängig machen, sondern deren inhalte in extra tabellen speichern.

ich werde nicht ganz schlau aus deinem design, zumal ich mir das t am anfang der tabellennamen auch sparen würde. ich hätte erst einmal drei tabellen in kopf:

1. produkte
2. eigenschaften (farbe, gewicht, etc.)
3. produkte_eigenschaften

in der dritten tabelle würde dann auch die lieferzeiten stehen, dann ist es nämlich wirklich sowohl vom produkt als auch von der eigenschaft abhängig. ich habe also erst einmal nur drei tabellen.

Ilja

[Twilo]

Hallo,

ich werde nicht ganz schlau aus deinem design, zumal ich mir das t am anfang der tabellennamen auch sparen würde. ich hätte erst einmal drei tabellen in kopf:

1. produkte
2. eigenschaften (farbe, gewicht, etc.)
3. produkte_eigenschaften

in der dritten tabelle würde dann auch die lieferzeiten stehen, dann ist es nämlich wirklich sowohl vom produkt als auch von der eigenschaft abhängig. ich habe also erst einmal nur drei tabellen.

ich vertseh nicht so ganz, wie du das mit nur 3 Tabellen lössen kannst/möchtest ;-)

ich habe z.B. ein produkt "test1" und "test2", dann eine eigenschaft auflage mit "1000 stück" und "2000 stück"

ich muss doch irgendwie speichern können, dass die eigenschaft eine auflage, gewicht, etc. ist, wo hast du das eingeplant?

ob es sinnvoller ist, die lieferzeit in der beziehungstabelle zu speichern, muss ich noch abwägen.

zwecks der History werde ich mir auch noch gedanken machen

mfg
Twilo

[Ilja]

yo,

ich habe z.B. ein produkt "test1" und "test2", dann eine eigenschaft auflage mit "1000 stück" und "2000 stück"

ich muss doch irgendwie speichern können, dass die eigenschaft eine auflage, gewicht, etc. ist, wo hast du das eingeplant?

tabelle produkte:

id name ....
-------------
1  test1
2  test2

tabelle eigenschaften:

id eigenschaft einheit
---------------------
1  auflage     Stückzahl
2  gewicht     Kilogramm

tabelle produkte_eigenschaften:

produkt_id eigenschaft_id wert minlieferzeit
1          1              1000 express
1          1              2000 24 stunden
1          2               100 express
2          1              5000 3 tage

der nachteil dieser art ist nun auch deutlichter zu erkennen, nämlich das man keine grossen unterscheidungen bezüglich der eigenschaften machen kann. alle werte, egal ob nun zahlen oder ein string werden in der gleichen spalte abgespeichert. der vorteil ist, man kann ohne in das design einzugreifen neue eigenschaften hinzufügen.

du musst abwägen, ob deine daten recht statisch sind, also doch lieber pro eigenschaft, die mehrfach vorkommen kann eine extra tabelle oder aber mehr dynamik und dann diesen ansatz.

Ilja

[Twilo]

Hallo,

ich habe z.B. ein produkt "test1" und "test2", dann eine eigenschaft auflage mit "1000 stück" und "2000 stück"

ich muss doch irgendwie speichern können, dass die eigenschaft eine auflage, gewicht, etc. ist, wo hast du das eingeplant?

tabelle produkte:

id name ....

1  test1
2  test2

tabelle eigenschaften:

id eigenschaft einheit

1  auflage     Stückzahl
2  gewicht     Kilogramm

tabelle produkte_eigenschaften:

produkt_id eigenschaft_id wert minlieferzeit
1          1              1000 express
1          1              2000 24 stunden
1          2               100 express
2          1              5000 3 tage

der nachteil dieser art ist nun auch deutlichter zu erkennen, nämlich das man keine grossen unterscheidungen bezüglich der eigenschaften machen kann. alle werte, egal ob nun zahlen oder ein string werden in der gleichen spalte abgespeichert. der vorteil ist, man kann ohne in das design einzugreifen neue eigenschaften hinzufügen.

du musst abwägen, ob deine daten recht statisch sind, also doch lieber pro eigenschaft, die mehrfach vorkommen kann eine extra tabelle oder aber mehr dynamik und dann diesen ansatz.

das ganze soll sehr flexibel sein, daher ist die Methode besser

ich habe mal die Formel umgebastelt

SELECT ROUND((  
(wert3._wert2 / 1000 * wert3._wert1 / 1000* wert4._wert1 * wert1._wert1/1000 * wert1._wert2) +  
((wert2._wert1 + wert2._wert2) * produkt._plattenkosten) +  
((((wert2._wert1 + wert2._wert2) * produkt._ruestzeitproplatte/60) + ((wert4._wert1 / CEIL(produkt._bogengroesse / (wert3._wert2 / 1000 * wert3._wert1 / 1000 * 1.1))) / produkt._maschinengeschwindigkeit) + produkt._einrichtzeit/60) * produkt._maschinenstundensatz) +  
(produkt._bogengroesse * wert1._wert1/1000 * wert1._wert2 * produkt._einrichtboegen) +  
ceil(wert3._wert2 / 1000 * wert3._wert1 / 1000 * wert4._wert1 * wert1._wert1/1000) * wert5._wert1) *  
gewinnfaktor._faktor*lieferzeit._faktor, 2) AS preis  
FROM t_lieferzeit lieferzeit  
INNER JOIN t_produkt produkt ON produkt._lieferzeit_id = lieferzeit._lieferzeit_id  
INNER JOIN t_gewinnfaktor gewinnfaktor ON gewinnfaktor._gewinnfaktor_id = produkt._gewinnfaktor_id  
  
INNER JOIN t_produkt_has_wert produkt_wert1 ON produkt_wert1._produkt_id = produkt._produkt_id  
INNER JOIN t_wert wert1 ON wert1._wert_id = produkt_wert1._wert_id  
INNER JOIN t_eigenschaft eigenschaft1 ON eigenschaft1._eigenschaft_id = wert1._eigenschaft_id  
  
INNER JOIN t_produkt_has_wert produkt_wert2 ON produkt_wert2._produkt_id = produkt._produkt_id  
INNER JOIN t_wert wert2 ON wert2._wert_id = produkt_wert2._wert_id  
INNER JOIN t_eigenschaft eigenschaft2 ON eigenschaft2._eigenschaft_id = wert2._eigenschaft_id  
  
INNER JOIN t_produkt_has_wert produkt_wert3 ON produkt_wert3._produkt_id = produkt._produkt_id  
INNER JOIN t_wert wert3 ON wert3._wert_id = produkt_wert3._wert_id  
INNER JOIN t_eigenschaft eigenschaft3 ON eigenschaft3._eigenschaft_id = wert3._eigenschaft_id  
  
INNER JOIN t_produkt_has_wert produkt_wert4 ON produkt_wert4._produkt_id = produkt._produkt_id  
INNER JOIN t_wert wert4 ON wert4._wert_id = produkt_wert4._wert_id  
INNER JOIN t_eigenschaft eigenschaft4 ON eigenschaft4._eigenschaft_id = wert4._eigenschaft_id  
  
INNER JOIN t_produkt_has_wert produkt_wert5 ON produkt_wert5._produkt_id = produkt._produkt_id  
INNER JOIN t_wert wert5 ON wert5._wert_id = produkt_wert5._wert_id  
INNER JOIN t_eigenschaft eigenschaft5 ON eigenschaft5._eigenschaft_id = wert5._eigenschaft_id  
  
WHERE wert1._eigenschaft_id=1 AND wert2._eigenschaft_id=2 AND wert3._eigenschaft_id=3 AND wert4._eigenschaft_id=4 AND wert5._eigenschaft_id=5 AND produkt_wert1._produkt_id = 1 AND wert1._wert_id = 1 AND wert2._wert_id = 3 AND wert3._wert_id = 6 AND wert4._wert_id = 7 AND wert5._wert_id = 9

im moment bezieh ich mich auf die lieferzeit vom produkt, was nicht ganz richtig ist
wie kann ich über mehrere Tsbellen den MIN() wert bestmmen?

also von produkt._lieferzeit_id, eigenschaft1._lieferzeit_id, eigenschaft2._lieferzeit_id, eigenschaft3._lieferzeit_id, eigenschaft4._lieferzeit_id, eigenschaft5._lieferzeit_id

laut phpMyAdmin braucht diese abfrage 0.0011 sekunden, meine andere Abfrage hatte 0.0033 sekunden gebraucht

SQL Create Script mit Daten

mfg
Twilo

[Ilja]

yo,

das ganze soll sehr flexibel sein, daher ist die Methode besser

hmm, brauchst du dann die alte abfrage noch, wenn es diese tabellen dann nicht mehr gegen wird ?

wie kann ich über mehrere Tsbellen den MIN() wert bestmmen?

über mehrere tabellen ist es überhaupt kein problem, du meinst sicherlich den MIN-wert aus verschiedenen spalten ? das geht zum beispiel mit dem IF Operator.

Ilja

[Twilo]

Hallo,

das ganze soll sehr flexibel sein, daher ist die Methode besser

hmm, brauchst du dann die alte abfrage noch, wenn es diese tabellen dann nicht mehr gegen wird ?

wie soll ich sonst den Preis berechnen?
habe ich irgendetwas übersehen?

wie kann ich über mehrere Tsbellen den MIN() wert bestmmen?

über mehrere tabellen ist es überhaupt kein problem, du meinst sicherlich den MIN-wert aus verschiedenen spalten ? das geht zum beispiel mit dem IF Operator.

ich hab die Funktion LEAST entdeckt, siehe Formel Korrektur

mfg
Twilo

[Ilja]

yo twilo,

bin zur zeit in hamburg und werde nur sehr wenig hier bei self sein. ich muss die hilfe ein wenig verschieben, aber vielleicht kann dir jemand anders weiterhelfen..

Ilja

[Twilo]

Hallo,

SELECT produkt._bogengroesse as _bogengroesse, produkt._einrichtzeit as _einrichtzeit, produkt._einrichtboegen as _einrichtboegen, produkt._plattenkosten as _plattenkosten, produkt._maschinengeschwindigkeit as _maschinengeschwindigkeit, produkt._maschinenstundensatz as _maschinenstundensatz, produkt._ruestzeitproplatte as _ruestzeitproplatte, wert1._wert1 AS _bedrgewicht, wert1._wert2 AS _bedrkosten, wert2._wert1 AS _breite, wert2._wert2 AS _hoehe, wert3._wert1 AS _vorderfarbe, wert3._wert2 AS _rueckfarbe, wert4._wert1 AS _auflage, wert5._wert1 AS _versdandt, ROUND((  
(wert2._wert2 / 1000 * wert2._wert1 / 1000* wert4._wert1 * wert1._wert1/1000 * wert1._wert2) +  
((wert3._wert1 + wert3._wert2) * produkt._plattenkosten) +  
((((wert3._wert1 + wert3._wert2) * produkt._ruestzeitproplatte/60) + ((wert4._wert1 / CEIL(produkt._bogengroesse / (wert2._wert2 / 1000 * wert2._wert1 / 1000 * 1.1))) / produkt._maschinengeschwindigkeit) + produkt._einrichtzeit/60) * produkt._maschinenstundensatz) +  
(produkt._bogengroesse * wert1._wert1/1000 * wert1._wert2 * produkt._einrichtboegen) +  
ceil(wert2._wert2 / 1000 * wert2._wert1 / 1000 * wert4._wert1 * wert1._wert1/1000) * wert5._wert1) *  
gewinnfaktor._faktor*lieferzeit._faktor, 2) AS preis  
FROM t_lieferzeit lieferzeit, t_produkt produkt  
  
INNER JOIN t_gewinnfaktor gewinnfaktor ON gewinnfaktor._gewinnfaktor_id = produkt._gewinnfaktor_id  
  
-- Papierart  
INNER JOIN t_produkt_has_wert produkt_wert1 ON produkt_wert1._produkt_id = produkt._produkt_id  
INNER JOIN t_wert wert1 ON wert1._wert_id = produkt_wert1._wert_id  
INNER JOIN t_eigenschaft eigenschaft1 ON eigenschaft1._eigenschaft_id = wert1._eigenschaft_id  
  
-- Größe  
INNER JOIN t_produkt_has_wert produkt_wert2 ON produkt_wert2._produkt_id = produkt._produkt_id  
INNER JOIN t_wert wert2 ON wert2._wert_id = produkt_wert2._wert_id  
INNER JOIN t_eigenschaft eigenschaft2 ON eigenschaft2._eigenschaft_id = wert2._eigenschaft_id  
  
-- Farbe  
INNER JOIN t_produkt_has_wert produkt_wert3 ON produkt_wert3._produkt_id = produkt._produkt_id  
INNER JOIN t_wert wert3 ON wert3._wert_id = produkt_wert3._wert_id  
INNER JOIN t_eigenschaft eigenschaft3 ON eigenschaft3._eigenschaft_id = wert3._eigenschaft_id  
  
-- Auflage  
INNER JOIN t_produkt_has_wert produkt_wert4 ON produkt_wert4._produkt_id = produkt._produkt_id  
INNER JOIN t_wert wert4 ON wert4._wert_id = produkt_wert4._wert_id  
INNER JOIN t_eigenschaft eigenschaft4 ON eigenschaft4._eigenschaft_id = wert4._eigenschaft_id  
  
-- Versandart  
INNER JOIN t_produkt_has_wert produkt_wert5 ON produkt_wert5._produkt_id = produkt._produkt_id  
INNER JOIN t_wert wert5 ON wert5._wert_id = produkt_wert5._wert_id  
INNER JOIN t_eigenschaft eigenschaft5 ON eigenschaft5._eigenschaft_id = wert5._eigenschaft_id  
  
WHERE wert1._eigenschaft_id=1 AND wert2._eigenschaft_id=2 AND wert3._eigenschaft_id=3 AND wert4._eigenschaft_id=4 AND wert5._eigenschaft_id=5 AND produkt_wert1._produkt_id = 2 AND wert1._wert_id = 1 AND wert2._wert_id = 3 AND wert3._wert_id = 6 AND wert4._wert_id = 8 AND wert5._wert_id = 9 AND lieferzeit._lieferzeit_id=LEAST(produkt._lieferzeit_id, eigenschaft1._lieferzeit_id, eigenschaft2._lieferzeit_id, eigenschaft3._lieferzeit_id, eigenschaft4._lieferzeit_id, eigenschaft5._lieferzeit_id)

ein kleinen erfolg hab ich schon... sie liefert mir das selbe Ergebnis :-)

mfg
Twilo