Der folgende Beitrag wurde am 25. 08. 2006, 18:09 Uhr von Twilo veröffentlicht.
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
--
Farbtabelle
Der folgende Beitrag wurde am 25. 08. 2006, 18:57 Uhr von Ilja veröffentlicht.
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
Der folgende Beitrag wurde am 25. 08. 2006, 20:38 Uhr von Twilo veröffentlicht.
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
--
Farbtabelle
Der folgende Beitrag wurde am 25. 08. 2006, 21:14 Uhr von Ilja veröffentlicht.
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
Der folgende Beitrag wurde am 25. 08. 2006, 21:29 Uhr von Twilo veröffentlicht.
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
--
Farbtabelle
Der folgende Beitrag wurde am 25. 08. 2006, 23:37 Uhr von Ilja veröffentlicht.
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
Der folgende Beitrag wurde am 26. 08. 2006, 09:00 Uhr von Ilja veröffentlicht.
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
Der folgende Beitrag wurde am 26. 08. 2006, 09:31 Uhr von Twilo veröffentlicht.
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
--
Farbtabelle
Der folgende Beitrag wurde am 26. 08. 2006, 14:37 Uhr von Ilja veröffentlicht.
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
Der folgende Beitrag wurde am 26. 08. 2006, 15:26 Uhr von Twilo veröffentlicht.
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
--
Farbtabelle
Der folgende Beitrag wurde am 26. 08. 2006, 16:02 Uhr von Ilja veröffentlicht.
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
Der folgende Beitrag wurde am 26. 08. 2006, 16:23 Uhr von Twilo veröffentlicht.
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
--
Farbtabelle
Der folgende Beitrag wurde am 26. 08. 2006, 15:12 Uhr von Twilo veröffentlicht.
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
--
Farbtabelle
Der folgende Beitrag wurde am 26. 08. 2006, 17:38 Uhr von Twilo veröffentlicht.
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
--
Farbtabelle
Der folgende Beitrag wurde am 26. 08. 2006, 20:49 Uhr von Ilja veröffentlicht.
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
Der folgende Beitrag wurde am 26. 08. 2006, 21:18 Uhr von Twilo veröffentlicht.
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
--
Farbtabelle
Der folgende Beitrag wurde am 26. 08. 2006, 22:26 Uhr von Ilja veröffentlicht.
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
Der folgende Beitrag wurde am 26. 08. 2006, 22:46 Uhr von Twilo veröffentlicht.
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 umgebasteltSELECT 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
--
Farbtabelle
Der folgende Beitrag wurde am 27. 08. 2006, 00:06 Uhr von Ilja veröffentlicht.
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
Der folgende Beitrag wurde am 27. 08. 2006, 00:14 Uhr von Twilo veröffentlicht.
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
--
Farbtabelle
Der folgende Beitrag wurde am 28. 08. 2006, 19:36 Uhr von Ilja veröffentlicht.
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
Der folgende Beitrag wurde am 27. 08. 2006, 00:10 Uhr von Twilo veröffentlicht.
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
--
Farbtabelle
© 1998-2013 SELFHTMLImpressumSoftware: Classic Forum 3.4
