SELFPHP: Version 5.8.2 Befehlsreferenz - Tutorial – Kochbuch – Forum für PHP Einsteiger und professionelle Entwickler

SELFPHP


Professional CronJob-Service

Suche



CronJob-Service    
bei SELFPHP mit ...



 + minütlichen Aufrufen
 + eigenem Crontab Eintrag
 + unbegrenzten CronJobs
 + Statistiken
 + Beispielaufrufen
 + Control-Bereich

Führen Sie mit den CronJobs von SELFPHP zeitgesteuert Programme auf Ihrem Server aus. Weitere Infos



:: Buchempfehlung ::

Websites optimieren für Google & Co.

Websites optimieren für Google & Co. zur Buchempfehlung
 

:: Anbieterverzeichnis ::

Globale Branchen

Informieren Sie sich über ausgewählte Unternehmen im Anbieterverzeichnis von SELFPHP  

 

:: Newsletter ::

Abonnieren Sie hier den kostenlosen SELFPHP Newsletter!

Vorname: 
Name:
E-Mail:
 
 

Zurück   PHP Forum > SELFPHP > PHP für Fortgeschrittene und Experten

PHP für Fortgeschrittene und Experten Fortgeschrittene und Experten können hier über ihre Probleme und Bedenken talken

Antwort
 
Themen-Optionen Ansicht
  #21  
Alt 08.09.2003, 17:09:48
Trialrider Trialrider ist offline
Anfänger
 
Registriert seit: May 2003
Ort: Oschatz/Sa.
Beiträge: 124
So, hier geht's auch nochmal weiter.

Das mit dem "confirm()" als onSubmit-Ereignis, habe ich gemacht und es geht wunderbar, diver. Thanx.

Allerdings habe ich noch keine Lösung dafür, mein hintergrund(-Haupt-)Fenster mittels Automatik zu refreshen. Da ihc mit Frames arbeite, kann ihc es auch nicht über ein Reload der URL machen. Vielleicht fällt mir daz ja noch was ein.

Aber was anderes:
Bis jetzt habe ich mir ehrlich gesagt noch keine große Platte über die Architekturen meiner versch. DBs gemacht. (Asche auf mein Haupt).

Zu dieser Tabelle "shiplist" sollen nun noch Bestellungen zugeordnet werden. Dafür gedenke ich "bestellungen" anzulegen. Ja, und ich habe nun doch "id"s eingebaut.

Empfiehlt es sich für die Verknüpfung/Zuordnung Bestellung-Container noch eine extra Tabelle zu machen, einfach mit zwei Spalten "best" und "cont"?

Zugegebener Maßen hat uns das auch nie einer richtig beigebracht weder auf'm Gym. noch in der BS...

Na dann bis morgen, Trialrider
__________________
Yesterdays, Todays, Tomorrows - Kicking off your sorrows!
Mit Zitat antworten
  #22  
Alt 09.09.2003, 10:14:48
diver-network diver-network ist offline
Junior Member
 
Registriert seit: Apr 2003
Ort: TÜ
Beiträge: 337
Hi Trialrider,

so aus dem Bauch heraus würde ich sagen, daß Du eher 3 (!) Tabellen brauchst:
Nr. 1 für die Container
Nr. 2 für die Bestellungen
Nr. 3 für die Zuordnung Bestellung - Container.

Dies alles aber unter Vorbehalt, da ich Deine Anforderungen nicht kenne und auch nicht weiß, wie Deine DB- Struktur im Moment aussieht.

Daher sollte ich diese mal sehen.
Wenn Du Access hast (ich weiß, Du hast die DB als MySQL, was ich auch besser finde) könntest Du dort die Tabellen mit den entsprechenden Feldern anlegen. Dabei brauchst Du Dir keine Gedanken über die Feldtypen zu machen. Anschließend machst Du ein ER- Diagramm (??), das bei Access "Beziehungen" heißt, machst einen Screenshot davon und stellst den auf Deiner HP zur Verfügung. Ich schaus mir das dann an und probiere, den DB Entwurt mal zu überarbeiten.


Zu Deiner Frage mit dem Refresh des Hauptfensters: Eventuell kannst Du es mit window.opener ansprechen und darin einen document.reload versuchen, sofern es diese Funktion gibt. Schau da aber mal bei selfHTML nach.


HTH,

Andy

P.S.: ID- Felder sind immer das erste, was ich in einer Tabelle anlege. Wichtig: Primary Key und AutoIncrement mit INT(11).
__________________
Delphine, Wale, Orcas und mee(h)r:
tauchen in Alor/Indonesien
http://www.alor-dive.com
Mit Zitat antworten
  #23  
Alt 09.09.2003, 10:24:22
Trialrider Trialrider ist offline
Anfänger
 
Registriert seit: May 2003
Ort: Oschatz/Sa.
Beiträge: 124
Guten Morgen, Andy.

Ich schrieb im letzten Post nur von zwei zusätzl. Tabs, da ich die für die Container schon habe "shiplist"...

Da wir in unserer Firma bisher noch nichts groß mit DBs hatten außer bissl Lotus Notes und R/3 gibt es auch kein Access (Auch ein Grund mehr auf das freie MySQL zu setzen)

Ich nehme MS SQL (das was bei MSO bei ist), müsste auch gehen und mach davon mal den Screenshot. Vielleicht hilfts.

Rein architektonisch kommt in die "bestellungen" ein Timestamp, durch wen, die Best.-Nr. und die ID. Die Beziehungstabelle zw. Best. und Cont. sammelt die Container in Abhängikeit der Bestellung (=>1:n ???).

Also ich stell's mal auf meine Seite.

Viele Grüße, Steffen
__________________
Yesterdays, Todays, Tomorrows - Kicking off your sorrows!
Mit Zitat antworten
  #24  
Alt 09.09.2003, 11:55:42
Trialrider Trialrider ist offline
Anfänger
 
Registriert seit: May 2003
Ort: Oschatz/Sa.
Beiträge: 124
So, Andy, habe die grafische Darstellung hochgeladen (So in etwa) und auch mal einen Dump der DB samt Tabs gemacht (Dump-File)

Ich werd erstmal meine Skripte zum Bearbeiten der Bestellungen schreiben und um die Contai er zuzuordnen. Werd dann am Ende wohl meine Auswertungen der "shiplist" anpassen müssen (Joinen und so...)

Vielen Dank und viele Grüße,
Steffen
__________________
Yesterdays, Todays, Tomorrows - Kicking off your sorrows!
Mit Zitat antworten
  #25  
Alt 09.09.2003, 14:04:24
diver-network diver-network ist offline
Junior Member
 
Registriert seit: Apr 2003
Ort: TÜ
Beiträge: 337
Hi Trialrider,

ich hab jetzt mal kurz über Deine DB geschaut und folgende Anmerkungen:

- nenne Deine Id- Felder "eindeutig", z.B. best_id
Dies erleichtert Dir hinterher bei den Zwischentabellen die Zuordnung der einzelnen IDs zu den Tabellen.
- Erweitere Deine Id- Felder auf INT(11). Mit INT(3) kannst Du maximal 128 (??), auf jeden Fall aber viel zu wenig Datensätze reinbekommen. Überprüf das einfach mal.

Und jetzt bitte nicht schlagen ;-)

Ich würde die Datenbank komplett überarbeiten:

Tabelle Container
- c_id als PK
- container_nummer
- container_groesse

Tabelle Bestellungen
- best_id als PK
- artikel *
- datum
- Menge_des_Artikels ***
- Preis ***
- sonstige Infos, die NUR(!) zu EINER(!) Bestellung gehören

Tabelle Schiffe
- ship_id als PK
- name
- maximale_container
- heimathafen **
- sonstige Infos, die NUR(!) zu EINEM(!) Schiff passen

Tabelle S_to_C (Schiff zu Container)
- stoc_id als PK
- ship_id (FK zu Schiffe, daher auch mein obiger Tipp)
- cont_id (FK zu Container)
- sonstige Infos, die NUR(!) diese EINE(!) Fracht angehen, z.B. eta, Abfahrt des Schiffes,...

Tabelle Best_to_Cont
- besttoc_id als PK
- best_id
- cont_id


*) Artikel würde ich sogar noch in eine weitere Tabelle packen und hier nur den FK speichern
**) Heimathafen / Land kann ebenfalls in eine weitere Tabelle
***) Wenn Artikel ausgelagert werden gehören diese Daten in eine Zwischentabelle, da n zu m Beziehung!!

Und jetzt ein paar Grundregeln des DB- Designs:

- Wann immer Du redundante (= doppelte) Daten haben könntest, z.B. Heimathafen, Artikel etc. sollten (eher müssen!) diese in eine separate Tabelle ausgelagert werden
- Besteht die Möglichkeit, daß eine Bestellung z.B. auf mehrere Container verteilt wird UND ein Container mehrere Bestellungen aufnehmen kann (ich denke, beides ist wahrscheinlich) werden die Tabellen über eine Zwischentabelle verknüpft (Stichwort n zu m Beziehung)
- Ist die Zuordnung Container zu Bestellung IMMER(!) eindeutig, sprich: Eine Bestellung kann immer nur in genau einen Container kommen und ein Container kann immer nur genau eine Bestellung transportieren ist es eine 1 zu n Beziehung und in einer der beiden Tabellen wird der PK der anderen Tabelle als Fremdschlüssel gespeichert.

Am "Einfachsten" ist es, sich immer zu fragen, ob es sein kan, daß eine n zu m Beziehung möglich ist. Falls ja: Zwischentabelle.

Ich weiß, daß meine Tipps eventuell eine komplette Umarbeitung Deines bisherigen Programms bedeuten können, aber glaube mir, solange keine Daten in der Datenbank sind ist es um einiges einfacher als wenn die Datenbank mal voll ist und Du dann die Daten mühevoll "umsortieren" musst.

Gruß und viel """Spaß""",

Andy
__________________
Delphine, Wale, Orcas und mee(h)r:
tauchen in Alor/Indonesien
http://www.alor-dive.com
Mit Zitat antworten
  #26  
Alt 09.09.2003, 15:08:19
Trialrider Trialrider ist offline
Anfänger
 
Registriert seit: May 2003
Ort: Oschatz/Sa.
Beiträge: 124
Huh, erst mal setzen... :)

INT(3) = max. 128 Sätze??? Ich denke INT mit der Länge 3 => 999, na dann wohl doch nicht.

Ok. Aber in der "shiplist" stehen nur diese Daten, wie sie jetzt geplant/gedacht usw. sind. Über mein Skripte soll eignetlich nur die Papierflut aufgefangen werden...und damit man(n) schneller findet.


Anmerkungen zu deinen Vorschlägen:

Tabelle "Container":
Es gibt nur die Container-Bezeichnung "container" in den Mails, die uns zugesandt werden.

Tabelle "Bestellungen":
Soll eigentlich nur sagen, welcher Container zu welcher Bestellung, dient mehr dazu im R/3 den entsprechenden Beleg "Bestellung" zu finden.

"Menge_des_Artikels", "Preis", "Sonstiges" nicht relevant für gedachte Anwendung...

Tabelle "Schiffe":
Würde auch nur "Name" enthalten, andere Infos liegen uns/mir nicht vor...

Tabelle "S_to_C":
Da "Schiff" und "Container" in einer Tabelle stehen ("shiplist") entfällt diese hier...

Tabelle "Best_to_Cont":
werde ich so nehmen, wie du vorgeschlagen hast. Der Feld/PK "besttoc_id" bezieht sich aber nur auf den jeweiligen Eintrag? Ich glaube, es handelt sich dann doch wohl eher um "n:m"-Beziehungen handelt:
  • Best. Cont.
    1 => 2
    1 => 3
    1 => 5
    2 => 2
    2 => 4
    3 => 6
    3 => 7
    usw.

So, hoffentlich frustets dich jetzt nicht, wenn ich deine Mühe und Hilfe in dieser^^ Form teilweise widerlege. Auch tu ich mich noch schwer damit, wie ich dann mit den ganzen id's "spielen" soll, hinsichtlich Selects, Insert bzw. Deletes...

Bis hier bin ich noch spielerisch gekommen, doch nun wirds wirklich holprig... Meinen Respekt und Dank ist die auf alle Fälle sicher. Schade ist nur, dass man sich davon leider ncihts kaufen kannn :))

Kannst du mir bitte mit helfen, meine und deine Vorstellung in Einklang zu bringen, so mit Abfrage bauen usw.?

Viele Grüße, Steffen
__________________
Yesterdays, Todays, Tomorrows - Kicking off your sorrows!
Mit Zitat antworten
  #27  
Alt 09.09.2003, 16:12:05
diver-network diver-network ist offline
Junior Member
 
Registriert seit: Apr 2003
Ort: TÜ
Beiträge: 337
Hi Steffen,

ich war und bin mir im Moment nicht sicher, ob INT(3) bis maximal 999 oder weniger / mehr geht (kanns grad nicht ausprobieren). Ich weiß aber, daß es sinnvoller ist, gleich auf INT(11) für den Primärschlüssel (PK) zu gehen als sich hinterher zu wundern, warum manche Daten nicht angezeigt werden. In den Datentypen der Tabellen sucht man den Fehler halt immer erst zuletzt.

Das Feld besttoc_id ist als Primärschlüssel für die Zwischentabelle gedacht und mit AutoIncrement "vorbelegt". Das macht hinterher die SELECTs etwas einfacher, als wenn Du die Kombination "best_id" + "cont_id" als UNIQUE und Primärschlüssel deklarierst.

Ob Du zwischen Bestellungen und Containern eine 1:n oder n:m Beziehung benötigst kann ich aus der Ferne nicht beurteilen, ebensowenig, ob die von mir vorgeschlagenen anderen Tabellen für Euch Sinn machen oder nicht.
Ich hab Dir ja ein paar Tipps gegeben, wie Du beurteilen kannst, was für Dich und Deine Anforderungen richtig bzw. besser ist.

Ob ich Dir auch weiterhin helfen kann weiß ich nicht, ich werd's auf jeden Fall versuchen ;-)
Für die SELECTs etc. brauch ich dann aber nochmal die aktuellste DB- Struktur, am Besten wieder als Screenshot (Beispieldaten und Dump brauch ich nicht unbedingt, schaden aber nicht).

Gruß,

Andy

P.S.: Bin morgen nicht erreichbar
__________________
Delphine, Wale, Orcas und mee(h)r:
tauchen in Alor/Indonesien
http://www.alor-dive.com
Mit Zitat antworten
  #28  
Alt 09.09.2003, 16:39:33
Trialrider Trialrider ist offline
Anfänger
 
Registriert seit: May 2003
Ort: Oschatz/Sa.
Beiträge: 124
Jo, Mahlzeit.

Ich bemüh mich, gemachte Vorschläge in zukünftigen Aufgaben mit einfließen zulassen. Es soll zum Beispiel noch einen Bereich "Informationen" und "Nachrichten" geben, also ein großer Fall für ID's... ;-)

Naja, in dieser werde ich bestimmt noch je eine History-Tabelle für "shiplist", "bestellungen" und "best_cont" (o.w.a.i.s.h.) benötigen, zwecks Änderungsverfolgung.

Ich werde die Struktur vervollständigen und dann wieder hochschieben. Derweil code ich das/die dyn. Formular(e) für die Bestell-Daten und deren Zuordnung.

Danke Dir erstmal Andy
(...und auch allen anderen, die helfen Licht zu machen...)

Na denn, bis demnächst
Steffen
__________________
Yesterdays, Todays, Tomorrows - Kicking off your sorrows!
Mit Zitat antworten
  #29  
Alt 11.09.2003, 11:39:01
Trialrider Trialrider ist offline
Anfänger
 
Registriert seit: May 2003
Ort: Oschatz/Sa.
Beiträge: 124
Servus Andy,

Ich habe mich gestern mal mit meinem Kollegen unterhalten bzgl. der DB-Struktur. Er kann zwar mit PHP und MySQL usw. nix anfangen aber mit ER-Modellen schon. Nach dem Abwägen des Für und Wider sollen es nun doch 5 Tabs werden analog deinen Vorschlägen. (Ich kann dabei ja nur dazulernen...: )

Eine Screenshot gibt es hier: Neue Struktur und den DB-Dump hier: Aufbau der Tabs.

Allerdings musst du mir da mal bitte mit beim Umschreiben der Skripte für die Übernahme der CSV-Daten und die Auswertungen/Aktualisierungen helfen (was die SQL-Anweisungen bwtrifft). Wie schon erwähnt, habe ich noch nicht viel mit ID's gearbeitet.

Hier sind die Links zu den Skripten der Reihe nach:
1. Modul-Menü ("einkauf.php")
2. CSV-Uploader ("datei_input_auto.php")
3. Inhaltsviewer bzw. Form für manuelle Eingabe ("datei_input_bearbeiten.php")
4. Liste der Lieferungen zum Anklicken ("lief_akt.php")
5. Bearbeiten der geklickten Lieferung ("lief_akt_bearbeiten.php")
6. Anzeigen der Lieferungen ("lief_auswerten.php")
7. Eingabe der Bestellinformationen ("best_zuordnen.php")
8. Die Formulare und SQL-Anweisungen für das Anlegen, Ändern und Zuordnen ("best_zuordnen_was.php")*

Gecodet habe ich bisher mit PHPEdit...Und, an der einen oder anderen Stelle müsste noch ein $_GET["..."] rein... Du musst jetzt nicht alles fertig liefern, ich bemühe mich selber drum, es hin zu bekommen. Aber du hast mehr Erfahrung als ich. ;-)

Vielen Dank für deine Hilfsbereitschaft und viele Grüße,
Steffen


*) muss ich noch weiter coden, bin leider nicht sehr weit gekommen gestern - gab andere probleme...
__________________
Yesterdays, Todays, Tomorrows - Kicking off your sorrows!

Geändert von Trialrider (11.09.2003 um 11:42:41 Uhr)
Mit Zitat antworten
  #30  
Alt 11.09.2003, 14:06:40
diver-network diver-network ist offline
Junior Member
 
Registriert seit: Apr 2003
Ort: TÜ
Beiträge: 337
Hi Steffen,

ich hoffe, ich klinge jetzt nicht überheblich aber es ist gut, daß Du Dir noch mal Gedanken zur DB gemacht hast.
Die DB Struktur hat bzw. sollte NIE!!! etwas mit der verwendeten Programmiersprache wie PHP, Java, ... zu tun haben und nach Möglichkeit auch nicht nur auf ein DB- System wie MySQL oder MS-SQL gemünzt sein. Letztere Aussage ist aber unter dem Vorbehalt, daß nicht spezielle Einschränkungen des DB- Systems dagegen sprechen. Außerdem ist dies NICHT auf die Datentypen der einzelnen Felder gemünzt, die unterscheiden sich fast immer.

Was meinst Du eigentlich mit "nicht viel mit ID's gearbeitet"? Eigentlich ist dies ganz einfach.
Mit ID meine ich eine eineindeutige (UNIQUE) Zahl, die den Primärschlüssel der entsprechenden Tabelle bildet.
Hierdurch hast Du immer(!) eine eindeutige Zuordnung deiner Daten bzw. eines Teils Deiner Daten zu dem entsprechenden gesamten Datensatz.
Des weiteren erlauben Dir Ids die Erstellung einer PK -> FK (Primary- zu Foreign-Key) Relation indem Du den PK der Tabelle 1 als FK in der Tabelle 2 ablegst und sie erleichtern die entsprechenden Abfragen.

Eine SELECT- Abfrage über mehrere Tabellen geht dann z.B. so: SELECT a.*, b.* FROM tabelle1 AS a INNER JOIN tabelle2 AS b ON a.id = b.id WHERE ....

Zu Deiner Frage bzgl. durchschauen der Skripte: Leider hab' ich auch nicht so viel Zeit, um alles durchzusehen. Ich helfe Dir eher, wenn Du ein konkretes Problem mit einer SQL- Abfrage hast, z.B. "Wie schaffe ich es, mir alle Container auf dem Schiff xyz anzusehen?".

Hier noch mal ein paar allgemeine Tipps:
- lagere Deine SQL- Abfragen in include Dateien aus. Dies erleichtert Dir später das Ändern der Abfragen sowie der Datenbank, sollte das wirklich einmal nötig sein.
- ich würde die id- Spalten an den Anfang der Tabelle legen, dies erleichtert die Übersicht und ist eigentlich so etwas wie ein Quasi- Standard.
- Warum steht eigentlich "product" und "quantity" noch bei den Schiffen? Das gehört meiner Meinung nach eher zu den Bestellungen oder zu den Containern, aber nicht zu einem Schiff. Schau Dir hierzu noch mal meine Antwort bzgl. DB - Design an. In eine Tabelle sollten nur "fachspezifische" Daten rein, sprich zu einem Schiff nur Daten, die für das Schiff bzw. dessen Identifikation wichtig sind (Kapitän z.B. würde ich wieder in eine neue Tabelle schreiben, da sich dieser ändern kann).

Gruß,

Andy
__________________
Delphine, Wale, Orcas und mee(h)r:
tauchen in Alor/Indonesien
http://www.alor-dive.com
Mit Zitat antworten
Antwort


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 
Themen-Optionen
Ansicht

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind aus.
[IMG] Code ist aus.
HTML-Code ist aus.

Gehe zu


Alle Zeitangaben in WEZ +2. Es ist jetzt 11:45:39 Uhr.


Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.


© 2001-2023 E-Mail SELFPHP OHG, info@selfphp.deImpressumKontakt