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

[Trialrider]

Hi Andy, danke für die schnelle Antwort.

Dann brauch ich also keine extra Tabelle für die einzelnen Bestellpositionen verwenden, da es ja in "best_prod" drinsteht:

id: 1 Best: 12345 Prod: 08154711 (1.Position)
id: 2 Best: 12345 Prod: 63457823 (2.Position)
id: 3 Best: 55555 Prod: 08154711
id: usw.

Ergo, ich kann es doch so lassen wie vorher. Sch... Dann klappt es nämlich auch einfacher mit verschiedenen Bestellern pro Bestellung (was aber in der Regel nicht vorkommt, da im SAP-Bestellkopf der erstellende Bearbeiter abgelegt wird).

Nix für Ungut, manchmal kann man es sich auch ganz schön kompliziert machen, wenn man versucht an alles zu denken.

Viele Grüße und Danke, Steffen

Edit 1:
Blödsinn, was ich da oben schreibe. In die "bestellungen" kommt nur einmal die angelegte Bestellung rein und dann über die Beziehungstabelle werden der Bestellung 12345 x Positionen zugeordnet...

So, muss es sein.

[diver-network]

Hi Steffen,

was aber in der Regel nicht vorkommt

würde mir an Deiner Stelle zu Denken geben. Wenn es auch nur einmal vorkommen kann gehören solche Dinge in separate Tabellen!!
Für Dich bedeutet das: Auslagern der Personendaten in eine separate Tabelle (hab ich bis jetzt auch nicht dran gedacht o(( ) und zwischen Bestellungen und Personen eine Zwischentabelle.

Gruß,

Andy

P.S.: Tabellennamen sind normalerweise im Plural, die Tabellenspalten im Singular ("Personen" als Tabelle, "Vorname" als Spalte).

[Trialrider]

Mmmh, hätte jetzt einfach den Besteller mit in die Beziehungstabelle "best_prod" gepackt. Aber ich werde eine "besteller"-Tabelle anlegen und diese aber wirklich mittels Funktion bedienen (sofern es mir nicht auf die Füsse fällt ;-)).

Die Beziehung zur Bestellung/Produkt mache ich in eine Tabelle "pos_best", wo die ID aus "best_prod" (quasi die Bestellpositionen) und eben die des Bestellers drinsteht.

So, dann wünsche ich mir einfach erstmal frohes Coden bis zum nächsten Felsen.

Danke, Andy.

MfG, Stefffen

[diver-network]

Hi Steffen,

wenn Du den Besteller mit in die Zwischentabelle zwischen Artikel und Bestellungen genommen hättest wären da wieder Redundanzen vorhanden.

Mit dem Coden würde ich wirklich erst dann anfangen, wenn das Datenbank Design endgültig steht. Vor allem, was SQL- Abfragen und deren Reihenfolge angeht. Ansonsten hast Du immer wieder doppelte Arbeit. Was natürlich immer geht ist das Formulardesign etc.

Bzgl. des DB- Designs von mir auch noch mal der Hinweis bzw. die Warnung(!!), daß ich Deine konkreten Anforderungen z.B. bzgl. Datenmengen und benötigter Speichertiefe der Daten nicht kenne und meine Tipps daher möglichst nahe an das "ideale" DB- Design gehen.
Wenn bei Dir also der Großteil der Informationen eh schon in SAP drin stehen und Du es theoretisch bei Dir gar nicht mehr speichern müsstest solltest Du etwas vorsichtig sein, daß Du nicht Eure eh schon bestehende Datenbank ablöst ;-) Ich befürchte nämlich, daß wir uns mit großen Schritten einem halben Shop oder Lagerhaltungssystem nähern, wenn auch mit anderen Verwendungszwecken.

Was anderes: Mit was erstellst Du die DB bzw. die Tabellen? Ich hoffe doch mit phpmyadmin ( www.phpmyadmin.net ) und nicht von Hand mit SQL- Befehlen.

Gruß,

Andy

[Trialrider]

Wenn du net im Schwabenländle sitzen würdest, hätt ich gesagt: "Schau mal auf ein Bier (oder zwei...) vorbei."

DB-Admin erledige ich mit phpMyAdmin. Vor einigen Jahren (2 oder 3) hatte ich es schon mal in der Mache, konnte aber nciht wirklich was damit anfangen. Doch heute will ich es nicht mehr missen müssen. Bei den MySQL-Befehlen kenne ich momentan noch nicht genug um alles ohne PMA zu machen ;-).

Aber nochmal zum Grund der "chinadb": Die richtigen Bestellungen werden über SAP abgewickelt. Die Chinesen senden uns nach Erhalt und bei Bestätigung vorab eine Datei mit den möglichen Lieferterminen der Container entsprechend der Bestellung(en).

Im SAP haben wir aber keine Möglichkeit nach außen sofort transparent zu hinterlegen, wann zu welcher Bestellung der/die Container eintrudeln. Ebenso müssen die Einträge beim Erhalt auf "erledigt" gesetzt werden können usw.

All dies wird momentan auf'm Papier gemacht - Jede Datei ausgedruckt, zur Bestellung geheftet, notfalls kopiert und weitergereicht und, und und...

Deshalb die DB-Lösung für'n Explorer, den hat bei uns hier jeder und wer was wissen will und darf, guckt einfach rein.

Die verknüpften Tabellen mit Bestellungsdaten füllen habe ich hoffentlich sauber hinbekommen:
[...]
Wie gesagt, habe es als funktion am Laufen und es funzt soweit. Nach diesem Strickmuster werde ich die Funktion zum Ändern basteln und dann auch die zum Zuordnen der Container (geht glaub ich einfacher).

Für Kritik habe ich immer zwei Ohren offen.

Wiederholt ein Danke für deine Unterstützung und viele Grüße,
Steffen

[diver-network]

Hi Steffen,

mir ist bezüglich der DB noch etwas eingefallen, was wir vergessen haben:
Es gibt im Moment keine Möglichkeit, teilweise gelieferte Bestellungen zu erfassen. Sprich: Wenn bei einem Auftrag 100 Kartons bestellt waren, aber nur 10 kamen hast Du ein Problem, das in der DB zu speichern.
Außerdem ist es glaube ich nicht möglich, festzustellen, in welchem Container welcher Teil bzw. welche Artikel einer Bestellung ist/sind.

Überleg' Dir also mal, wo und wie Du diese Informationen in der DB speichern kannst, falls Du dabei Hilfe brauchst meldest Du Dich halt wieder.

Gruß,

Andy

[Trialrider]

Hallo Andy,

ja damit (10 von 100) hast du recht. Ich habe dafür eine Tabelle "best_pos_menge" (bpm_id, bp_id, bestellmenge, liefermenge, elkz) ausgedacht.

Allerdings habe ich gerade eben bei phpMyAdmin falsch gedrückt und bestätigt, und somit meine gesamte "chinadb" gekillt. F***, Bulls*** *fluchendandiedeckespring*

Also werde ich die DB nochmal vom Papier her zusammenbauen müssen.

Was Aussagen über die Zuordnung von Art. zu Container betrifft, ist dies möglich. Die Container sind den Bestellungen zugeordnet über "best_cont", und die Artikel den Containern mittels "prod_cont". Außerdem hab eich noch eine Tab "best_prod", die Positionen speichert, da ja auch zwei verschiedene Positionen das gleiche/selbe Produkt enthalten können...

Hoffe, dass ist was du suchtest.

Viele Grüße, Steffen

[diver-network]

Hi Steffen,

wenn ich mich jetzt nicht täusche kannst Du die gelieferte Menge auch in der Zwischentabelle zwischen Bestellungen und Artikeln speichern. Dort ist ja schon ein Feld "Menge" vorhanden, das die bestellte Menge angibt. Dazu fügst Du einfach noch ein Feld "gelieferte Menge" hinzu, in der dann die tatsächlich gelieferten Artikel drinstehen.
Vorteil dieser Lösung: Keinen weitere Tabelle
Nachteil: Du kannst nicht (sinnvoll) erfassen, wann die Lieferung in welchen Häppchen kam. Z.B. "Am 1. kamen 10 Kartons, am 5. noch mal 10 und am 11. der Rest".
Alternative: Eine weitere Tabelle, die Du an die ZWISCHENTABELLE zwischen Artikeln und Bestellungen hängst. Diese verknüpfst Du über die jeweiligen ids.
Beispiel:
Tabelle Lieferdaten
- liefer_id (PK)
- best_art_id (Verknüpfung zur Zwischentabelle)
- liefermenge
- lieferdatum

An die Zwischentabelle Best_Art kannst Du außerdem noch ein Feld "geliefert" anfügen, in dem gespeichert wird, wann die Bestellung komplett geliefert wurde. Dies ist zwar eine gewisse Redundanz zu den in der Tabelle Lieferdaten gespeicherten Infos, erleichtert Dir aber die Abfrage, welche Bestellungen noch offen sind.

Was die Zuordnung einzelner Artikel zu einem Container angeht ist dies, so wie Du es beschreibst, möglich.

Was das versehentliche Löschen der DB angeht kann ich Dir für die Zukunft nur raten, verschiedene Zwischenstände des DB- Entwurfs unter anderen DB- Namen zu speichern und eventuell Sicherungskopien des "DB- Ordners" von MySQL zu machen. Ansonsten hoffe ich, daß Du die DB wieder hinbekommst. Es wäre auch gut, wenn Du noch mal die aktuellste Version des DB- Designs bereitstellst. Ich schau mir das dann noch mal an, eventuell finde ich noch was zum Verbessern.

Da die SQL- Abfragen so langsam schwierig werden würde ich Dir empfehlen, hierfür Access zu nehmen. Ich werde die DB in jedem Fall noch mal in Access nachbilden, damit ich Dir gegebenenfalls bei den Abfragen helfen kann.

Gruß,

Andy

P.S.: Mach Dir auch Gedanken bzgl. Datentypen und, für später, welche Indexe Du anlegen willst.

[Trialrider]

"chinadb" steht wieder. Hier gibt es den DB-Dump. Ich habe erstmal nur 4 Teilenummern und eine Handvoll Bestellungen eingetragen. Sprich, die Insert funktionieren für die Teilenummern, Bestellungen und Besteller.

Für die CSV_Daten bzw. die manuell eingegebenen muss ich die Skripte noch umschreiben, damit auch da alles in die richtigen Tabs läuft. Im Zuge des Wiederaufbaus habe ich die "shiplist" bereinigt und doch noch eine sep. Tab "steamer" angelegt.

So sehen die Verknüpfungen jetzt aus: Bild

Wie du siehst, stehen die Mengen zur Bestellung und Position in einer Tabeller zur Beziehung zw. Produkt/Position und Bestellung.

So wie die DB jetzt steht würde ich sie gern lassen wollen. Mal sehen ob ich irgendwo Acces herbekomme, allerdings hab ich nur MSO-XP-SBE. Mein Padant wäre MS-Query, was da dabei ist. Notfalls mit OpenOffice?

So, das war's erstmal von mir vorm WE. Ich werd die Lieferskripte noch modifizieren.

Dir wünsche ich ein schönes Wochenende. Bis denn,

Steffen

[diver-network]

Hi Steffen,

if (MSO == "Microsoft Office") {
echo "Schau mal, ob Du Access nachinstallieren kannst";
} else {
echo "Vermutlich nicht dabei";
}

;-)

SBE kenne ich nicht. MS Query ist wohl der Query Analyzer des MS-SQL Servers? Falls ja erlaubt dieser m.W. keine grafische Erstellung von SQL- Abfragen.
Open oder Star Office haben als einzigen Nachteil den, daß bei denen leider kein Datenbankprogramm wie Access dabei ist.

Kurz und gut, Du musst die Querys dann wohl von Hand schreiben. Der Vorteil ist aber auch klar: Du lernst einiges dabei und weißt genau, warum was und wie (nicht) geht ;-) Nachteil: sehr Zeitaufwändig.

Anmerkungen zur DB:

- Die Relation zwischen Shiplist und Steamer ist doch 1:n, sprich: Zu einer Shiplist gehört immer nur ein Schiff und niemals mehrere. Falls dem so ist muß die Tabelle st_steamer_0 weg.

- Tabelle best_prod_0: Das Feld (Bestell)"datum" würde ich doch raus machen (sorry, mein Fehler im vorigen Posting).
Stattdessen fügst Du eher in der Tabelle "bestellungen_0" ein Feld "komplett_geliefert_am" ein und füllst das, wenn die Bestellung komplett ist.
Wo speicherst Du die bestellte Menge des Artikels?? Diese Information gehört in diese Zwischentabelle. Mit "pos" ist doch nur die Position des Artikels auf dem Lieferschein gemeint.

- Tabelle best_pos_menge: Das Feld "best_menge" gehört in die Tabelle "best_prod_0" (s.o.).

- Tabelle "container_0": Das Feld "quantity" gehört dort nicht rein. Wenn dieses die Information enthalten soll, wieviele Produkte in dem Container sind gehört diese in die Zwischentabelle zwischen Artikel und Container (s.u.). Allerdings bekommst Du diese Information so oder so über die Tabelle "bestellungen_0" geliefert.

- Verbindung zwischen "container_0" und "products_0": Wenn Du damit speichern willst, welches Produkt sich in welchem Container befindet geht das. Allerdings bekommst Du so nicht raus, zu welcher Bestellung dieses gehört.
Vorschlag deshalb (nicht schlagen ;-) ): lösche die Tabellen "best_cont_0" und "prod_cont_0" und füge statt dessen die Container-id als FK in die Tabelle "best_prod_0" ein. Somit hast Du zu jeder Bestellung sowohl die Zuordnung zu den Artikeln und gleichzeitig auch noch die Zuordnung zu den Containern. ACHTUNG: Rede hierüber unbedingt noch mal mit Deinem Kollegen, der sich mit ER- Modellen auskennt oder frage zusätzlich jemand anderes, der sich mit Datenbankdesign auch auskennt!!

- Verbindung zwischen Besteller_0 und best_prod_0: Diese Verbindung ist falsch. Die Besteller stehen in einer Beziehung zur Bestellung und nicht zu der zwischentabelle zwischen Bestellungen und Produkten. Ob eine Bestellung auch von mehreren Bestellern kommen kann kann ich nicht beurteilen. Vom Gefühl nach ist dies aber eine 1:n Beziehung und nicht n:m. Daher: Tabelle pos_besteller_0 weg.

Neues Design: Tabelle "bestellungen" mit Feld "besteller_id" und Tabelle "besteller" mit "besteller_id" als PK sowie den Daten zum Besteller.

Allgemein:
- Stelle die Primärschlüssel der Tabellen an den Anfang. Dies ist um einiges übersichtlicher. Nenne zusätzlich die Primärschlüssel der Zwischentabellen so, wie die Tabelle heißt (+ id natürlich) und kürze dies kaum.
- Nenne Deine Felder sprechend und spare nicht mit Buchstaben. In ein paar Wochen/Monaten/Jahren weißt Du eventuell nicht mehr, was was ist.

Was mir auch auffällt: Du verwendest überall Zwischentabellen. Diese benötigst Du aber nur bei n:m Beziehungen und nicht bei 1:n Beziehungen.
Der Unterschied zwischen diesen beiden Arten ist: Eine Bestellung kann aus 1 oder n Artikeln bestehen. Gleichzeitig kann ein Artikel in mehreren Bestellungen vorkommen. Ergo: n:m und Zwischentabelle
Ein Besteller (Kunde) kann mehrere Bestellungen aufgeben aber gleichzeitig kann eine Bestellung nur von einem einzigen Kunden kommen. Ergo: 1:n Beziehung mit der Speicherung der Kunden-id (PK) bei den Bestellungen (als FK).
Auch bei Zwischentabellen kann noch einmal eine 1:n oder, seltener, n:m Beziehung zu einer anderen Tabelle bestehen.

So, ich denke mal, daß demnächst die DB fertig ist und hoffe halt, daß Du nicht denkst, daß ich es damit übertreibe. Aber jeder Tag, den Du vorher in Dein DB Design steckst erspart Dir später, wenn es um Erweiterungen/ Änderungen geht, eine Woche Arbeit und einiges an (Angst)Schweiß, wenn es um das richtige Übertragen der Daten geht. Und Erweiterungswünsche seitens der Anwender kommen sicher irgendwann.

Dir auch ein Schönes Wochenende,

Andy