Benötige Hilfe für dyn. Abfrage mittles PHP

[Trialrider]

Servus, Andi.

Bevor WE ist:
"SBE" steht für "Small Business-Edition" (Word, Excel, Publisher, bissl Tools, u.a. MS Query und nix weiter).

Die "_0" wurden vom Query-Tool gemacht, auch die ID's stehen oben dran (siehen Dump-File).

- Die Relation zwischen Shiplist und Steamer ist doch 1:n

Ja, ist ja richtig - Blindheit ist bestimmt das richtige Wort dafür.

Zum Kennzeichnen der kompletten Position gibt es in "best_pos_menge" das Feld für ein Endlieferkennzeichen. Ich habe dieses, die Menge und die Positionsnummer deshalb in eine extra Tabelle, weil ich in "best_prod" ja nur Bestellung und [b]Produkt[/u]
speichere. Oder ist es in dieser Tabelle dann egal, ob ich da für eine Bestellung 3x das gleiche Produkt drin stehen habe?

In "best_prod" speicher ich die ID der Bestellung (b_id), die des Produktes (p_id) und dazu die Positionsnummer (aus dem Formular uebernommen). Somit gibt es pro Bestell-Position und egal zu welcher Bestellung genau 1 ID. Damit ich dann die Menge zuordnen kann und auch wiederfinde habe ich mir eben "best_pos_menge" überlegt, wo ich dann eben die beiden Mengen und das ELKZ reinschreibe.

"quantity" in "container" verschiebe ich nach "prod_cont", da es die Menge eines Produktes pro Container enthalten soll. Habe ich verunglückt abgelegt ;-)

Über die Zuordnung der Container zur Bestellung kann ich doch Rückschlüsse auf das Produkt ziehen, da ja nur drin sein kann, was bestellt wurde und das Produkt steht ja in der Bestellung. So nach dem Motto:

Wenn die Bestellung B_A den Container C_A hat, liefer den Container für das bestellte Produkt P_A (aus Bestellung B_A) zurück. Gibt es einen Container, dann schaue ob Container = Container C_A usw... *stirnrunzelundfragendguck*

Zu den Bestellern: du hast mir weiter oben geschrieben, dass ich mich fragen soll, ob es nicht doch so sein kann, dass verschiedene Positionen von anderen bestellt werden könnten. Das Ergebnis meiner Überlegng ist eben "pos_besteller". Im SAP ist es wirklich so, das es pro Bestellung einen einzigen Bearbeiter gibt. Aber ich arbeite ja nicht für SAP... ;-) Notfalls kille ich die Tabelle eben.

Zu den ID-Bezeichnern: diese setzen sich bei den Haupttabellen aus min. dem ersten Buchstaben und "_id" zusammen, bei den Zwischentabellen aus den Buchstaben der jeweiligen Fremdschlüssel und "_id"...

Wegen den Zwischentabellen: "steamer" und "sl_steamer" fliegen raus, da hast du recht^^. Aber ein Container kann doch mal wieder auftauchen (wenn es auch Steinzahl-tausend Jahre dauern mag), also schmeiß ich doch die "bewst_cont" weg :-)) Ergo auch die "prod_cont"??? Und packe die "p_id" in die Containertabelle mit rein??? Aber die für die Besteller "pos_besteller" lasse ich, wenn nur ein verantwortlicher pro Bestellung dann würde sie rausfliegen, aber ich lass mal lieber pro Position ein Besteller zu und somit auch die Tabelle.

So, geschafft. ;-)
Ich "entlass" dich jetzt auch ins WE. Vielen, vielen Dank für deine Geduld mit mir Amateur/Laien/Newb/usw.

Viele Grüße, Steffen

[diver-network]

Hi Steffen,

ich hab' mir übers WE noch mal Gedanken bzgl. des DB- Designs gemacht.
Schau's Dir mal an:
http://www.diver-network.de/selfphp/trialrider/db.jpg (die DB)
http://www.diver-network.de/selfphp/trialrider/dump.txt (MySQL Dump)
http://www.diver-network.de/selfphp/...r/nordwind.jpg (Nordwind DB, die bei Access dabei ist)
http://www.diver-network.de/selfphp/...der/readme.txt (zusätzliche Infos zu den DBs)


Gruß,

Andy

[Trialrider]

Moin Andy,

erstmal vielen herzlichen Dank für deine Bemühung(en). Leider bin ihc am WE zu Haus nicht sehr weit gekommen, aber da habe ich Access gefunden, installiert und den bis dahin aktuellen Stand der DB nachzubilden...

Die "invoice_no" gehört sicher zu einer Bestellung, doch bei uns wird telef. oder per Mail bestellt und erst wenn die Ware da, wird im System (SAP) eine Bestellung erfasst (Leider).
Und die Rechnung wird containerbezogen erstellt.

Womit mir schon beim nächsten sind:
Mit deinem neuen Vorschlag für die Container-Schiff-Zuordnung, sieht die Tabelle ähnlich aus wie mein erster Gedanke, die Lieferungen zu erfassen (nur dass du die Schiffe ausgelagert hast ;-)). Vielleicht ist es doch besser eine/mehrere Tabelle(n) zu machen. Mein Vorschlag zur Güte:

HT1 "steamer(steamer_id, heimathafen, name)"
HT2 "container(container_id, name)"
BT1_2 "zw_steamer_container(zw_steamer_container_id,steamer_id, container_id,container_size, eta, schedule_date, ship_date, bl_no, invoice_no)"

Damit gibt es in "steamer" immer nur ein Schiff, in "container" immer nur einen Conatiner, aber dafür mögliche n:m Beziehungen, wenn der Container und/oder das Schiff mal wieder auftaucht.

Nur eine Anmerkung noch. Alle Infos laufen in den "bestelldetails" zusammen, damit bekommen meine User aber die Vorgehensweise vorgeschrieben => erst Produkte, dann Bestellung, und jetzt erst Container zuordnen (Ist ja auch richtiger). Sie ordnen aber meist den Containern die Bestellung zu... Da bleibt mir bloß, sie an diese Reihenfolge zu nageln und sie es auch im Real-System so machen zu lassen.

Danke nochmal und schöne Woche, bei Fragen weiß ihc ja wo ihc dich finde...

Viele Grüße,
Steffen

[diver-network]

Hi Steffen,

Dein Vorschlag bzgl. der Tabellen für die Zuordnung Schiff/Container sieht gut aus, die Container Tabelle hab ich nur weg gelassen, weil Du ja mal geschrieben hast, daß es Jahre dauert, bis der selbe Container wieder kommt.

Deine User müssen (hoffentlich) ihr Verhalten nicht allzusehr umstellen.
Sobald mal die möglichen Produkte in der DB gespeichert sind (muß ja nur einmal geschehen) können sie auch wieder damit anfangen, die Bestellungen den Containern zuzuordnen.
Du mußt hier halt in der Anwendung etwas sauberer Programmieren und eventuell für das Zwischenspeichern von Informationen weitere Tabellen anlegen oder die Daten anderweitig temporär wegspeichern.
(Achte auch darauf, welche Felder Du mit NULL bzw. NOT NULL deklarierst, nicht daß Du dann von der DB eine auf die Finger bekommst, wenn Du erst später die Informationen eintragen willst/kannst).

Gruß,

Andy

P.S.: Bin erst morgen mittag wieder erreichbar.

[Trialrider]

Dein Vorschlag bzgl. der Tabellen für die Zuordnung Schiff/Container sieht gut aus, die Container Tabelle hab ich nur weg gelassen, weil Du ja mal geschrieben hast, daß es Jahre dauert, bis der selbe Container wieder kommt.

Ja aber er kann auch schon morgen wieder auftauchen, weil er nur im Inland unterwegs war...

Deine User müssen (hoffentlich) ihr Verhalten nicht allzusehr umstellen.
Sobald mal die möglichen Produkte in der DB gespeichert sind (muß ja nur einmal geschehen) können sie auch wieder damit anfangen, die Bestellungen den Containern zuzuordnen.
Du mußt hier halt in der Anwendung etwas sauberer Programmieren und eventuell für das Zwischenspeichern von Informationen weitere Tabellen anlegen oder die Daten anderweitig temporär wegspeichern.
(Achte auch darauf, welche Felder Du mit NULL bzw. NOT NULL deklarierst, nicht daß Du dann von der DB eine auf die Finger bekommst, wenn Du erst später die Informationen eintragen willst/kannst).

Sie haben momentan die Contaienrdaten in ihrer Email und da steht zBsp. das Produkt schon drin. In der DB-Umsetzung würden sie zuerst ihre Containerdaten eingeben und da fehlt dann der Bezug zw. Container und Produkt, da es ja nun erst bei den Bestellungen auftaucht... (=> wird's doch eine Tab "container_product" gben???)

So weit von mir,
Werde mich mal ans INSERT-Schreiben machen, und werd dabei von hinten(bei den einfachen Tabellen ;-)) anfangen.

Viele Grüße, Steffen

[Trialrider]

Hallo Andy,

ähnlich wie mit den Bestellern habe ich auch für die Schiffe und Container vor, eine Funktion zu verwenden.

Allerdings bereitet mir das Produkt aus dem CSV-File Sorgen. Ich könnte die "product_id" ja mit in die Tabelle "zw_steamer_container" packen, aber dann steht die "product_id" sowohl da, als auch in "bestelldetails" drin.

Wie wäre es wenn ich zwischen "zw_steamer_container" und "bestelldetails" eine Tabelle hänge die sowohl diese beiden IDs hat als auch die vom Product? Bildlich sieht es etwa so aus. Dreh und Angelpunkt wäre dann "steamer_cont_bestelldetails".

BTW: Ich habe mal noch ein etwas in "bestellungen" (1)und "bestelldetails" (2) geschraubt, und zwar habe ich (1) das bestelldatum zum belegdatum gemacht und das lieferdatum nach (2) verschoben. In (2) habe ich dann noch ein bestelldatum hingemacht.

So, bis dann und noch einen schönen Tag.
Gruß, Steffen

[diver-network]

Hi Steffen,

mein neuer Vorschlag zu der DB:
Schau's Dir mal an:
http://www.diver-network.de/selfphp/...ider/db_v2.jpg (die DB)
http://www.diver-network.de/selfphp/...er/dump_v2.txt (MySQL Dump)
http://www.diver-network.de/selfphp/.../readme_v2.txt (zusätzliche Infos und Erklärungen)


Gruß,

Andy

[Trialrider]

Servus Andy,

freue mich für dich, dass du genug Arbeit hast ;-), wenn man bedenkt, dass die Zahl derer ohne immer größer wird.

Ich kann mich mit deiner Verknüpfung "container" und "bestelldetails" nicht wirklich anfreunden ('tschuldige bitte meinen Dickkopf). Wenn ein Container mal auf zwei Schiffen unterwegs war, sollte es ein Problem werden. Denn in den Bestelldetails weiß ich dann nicht mehr mit welchen Schif der Container gekommen ist...Ist es da nicht besser "zw_steamer_container" mit "bestelldetails" zu verbinden? Ich mache es erstmal so.

Trotzdem, mir ist ein Licht angegangen bzgl. der Erfassung von Containern (die bisherige Papiervorgehensweise). Freilich kann man überall alles reinschreiben und auf alle Fälle auch die CSV-Daten in "bestelldetails" (Manchmal bin ich aber auch blind).

Wenn ich aber dein beschriebenes Problem vermeiden will, dann werde ich den Usern bei den CSV-Daten noch ein Feld (SELECT-Box) anbieten, wo die möglichen Bestellungen mit entspr. Produkt usw. drinstehen. Als Value der jeweiligen OPTION steht dann die "bestelldetails_id" zwecks Satz-Update. Wenn es leer gelassen wird, dann wird der Satz hinzugefügt.

Würde mich freuen da mal eine Hilfe bei der SQL-Syntax (SELECT ... FROM ... ) für SELECT-Boxfüllung zubekommen.

Nochwas anderes: Ich kann mir das hier optisch nicht so richtig vorstellen (allerdings fehlt nur die bestellung, Container usw. und Produkt kommen aus dem CSV-File):

Zu Deiner Frage, wie Du es machen kannst, wenn Deine Kollegen zuerst den Container auswählen und dann diesem die Artikel sowie Bestellungen zuordnen**:

Speichere zuerst die Containerdaten in der Tabelle "container" ab. Diese PKs merkst Du Dir, egal wie und wo.
Anschließend wählen die Kollegen die Artikel aus und verteilen sie auf die Container. Da Du dann ja sowohl die Mengen, den Schlüssel des Artikels und des Containers hast kannst Du diese Daten in der Tabelle "bestelldetails" endgültig speichern....

Naja, ist nicht ganz so tragisch. Ich werde versuchen, dass sich die User an die Spielregeln halten. Werd mal sehen, vielleicht baue ich noch eine LOG-Tabelle, wo alle DB-Aktionen reingeschrieben werden. ;-)

So, bis denn. Werde da mal weiter coden. Und, Danke für den Buchtipp. Gibt's mittlerweile schon in 3. Auflage (29,95 EUR).

Viele Grüße, und hoffentlich klappts mal, dass ich dir irgendwie richtig Danken kann.

Steffen

P.S.: Wie kann ich schauen ob es einen Satz CSV-Daten schon gibt, damit der User ihn nicht ausversehen mehrmals eintragen kann? Einfache Selects werden sicher nicht ausreichen? Die Skripte gibt es hier:
Skript zum Hochladen,
Skript zum Bearbeiten (erschwerend kommt hinzu, dass es ja noch eine zusätzliche Selectbox s.o. gibt...),
Skript mit div. Funktionen,
CSV-Daten aus Email

P.S.S.: Und hier nochmal mein Dump mit Daten von Heutemorgen... Bitte klicken.

[diver-network]

Hi Steffen,

nur eine kurze Rückmeldung. Mehr kommt (hoffentlich) heute abend:

Wenn ein Container mal auf zwei Schiffen unterwegs war, sollte es ein Problem werden. Denn in den Bestelldetails weiß ich dann nicht mehr mit welchen Schif der Container gekommen ist

Du hast Recht, da hab' ich nicht dran gedacht o((. Also muß man doch zw_container_steamer mit bestelldetails verbinden und dann über diese Tabelle an die Infos zum Container kommen. Ich werde mir das aber später noch mal genauer ansehen.

Gruß,

Andy

[Trialrider]

So, bzgl. der Geschichte mit den Bestellungen beim Übernehmen der CSV-Daten: Habe es so gemacht:
[...]
Zum Eintragen in die DB mache ich es momentan so:
[...]
Für andere Lösungen (auch um was dazu zu lernen) bin ich immer zu haben.

So long, Steffen