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 ::

PHP 5.3 & MySQL 5.1

PHP 5.3 & MySQL 5.1 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
  #31  
Alt 11.09.2003, 16:53:22
Trialrider Trialrider ist offline
Anfänger
 
Registriert seit: May 2003
Ort: Oschatz/Sa.
Beiträge: 124
Hi diver,

habe nur eben mal cross gelesen... Die Containerdaten hab ich glatt vergessen - die wechseln noch die Tabelle. Ich verstehe dieses Forum hier als Hilfs und Lernmitel... also nichts an Überheblichkeit gefunden.

Mit dem "wenig ID's" => was zBsp Joins angeht und solche Sachen...Der Container und das Product sowie Menge stehen ja in einem File, wie sollten die Skripte aussehen damits in die richtigen Tabs geht und so weiter...


Was INT(11) bzw INT(3) angeht:
[...]
packt mir in 16 Sek. 3267... Sätze in die Tabelle... und setzt auch die IDs richtig. Scheint dann wohl egal zu sein ;-)

Viele Grüße, Steffen
__________________
Yesterdays, Todays, Tomorrows - Kicking off your sorrows!

Geändert von Trialrider (02.10.2008 um 10:57:23 Uhr)
Mit Zitat antworten
  #32  
Alt 12.09.2003, 09:48:05
diver-network diver-network ist offline
Junior Member
 
Registriert seit: Apr 2003
Ort: TÜ
Beiträge: 337
Hi Steffen,

zu der Frage, wie ein Skript zum Auslesen von Daten aus einem File aussehen soll kann ich leider nicht viel beitragen, da ich es selber ncoh nicht gemacht habe.
Ich meine aber, es gab hierzu schon ein paar gute Threads bzw. Antworten, eventuell von C4. Schau da mal nach.

Was ich weiß ist, daß es von MySQL ein paar Befehle gibt, Daten aus einem formatierten File direkt in die Datenbank zu lesen. Und zwar OHNE Umweg über PHP. Schau mal im MySQL Handbuch nach unter "mysqlimport" oder "LOAD DATA INFILE". Dort stehen ein paar Dinge dazu.
Ansonsten mußt Du glaube ich den Inhalt des Files in eine Variable packen und dann mit String- Operationen anhand von Trennzeichen auf einzelne Variablen aufteilen.

Zu den Fragen bzgl. SQL Syntax: Schau Dir hierzu auch mal die Hilfen im MySQL Handbuch an, dort ist einiges beschrieben. Außerdem gibt es die Seite http://www.databasejournal.com, auf der einiges über SQL drin steht, u.a. ein kleines Toutorial. (THX an einen Poster hier auf SelfPHP, der die URL mal gepostet hat) Natürlich versuche ich aber auch, bei konkreten Problemen zu helfen.

Zu INT(11) vs INT(3): Ich dachte, bei INT(3) ist relativ bald schluß mit den Zahlen. Muß mich mal etwas schlauer machen und eventuell daheim auch mal ausprobieren. In jedem Fall nochmal der Hinweis, da unbedingt drauf zu achten. Nicht daß es irgendwann mal Fehler gibt und es daran lag, daß INT(3) am Ende ist.

Gruß,

Andy

P.S.: Noch ein kleiner Tipp zu SQL: Wenn Ihr im Geschäft MS Office (Professional) habt ist da auch Access dabei. Dort kannst Du Dir SQL Abfragen auch zusammen klicken und meistens direkt in MySQL übernehmen. Prüfe die Befehle z.T. auch mal direkt in PHPMyadmin, da dort ziemlich gute Fehlermeldungen kommen.
__________________
Delphine, Wale, Orcas und mee(h)r:
tauchen in Alor/Indonesien
http://www.alor-dive.com
Mit Zitat antworten
  #33  
Alt 12.09.2003, 10:10:07
Trialrider Trialrider ist offline
Anfänger
 
Registriert seit: May 2003
Ort: Oschatz/Sa.
Beiträge: 124
Eine wunderschönen guten Morgen,

voller Tatendrang für diesen für mich rel. kurzen Tag bin heut durchs Tor spaziert...

Habe mal noch 3 Tabs dazugemacht: "products", "best_prod" (für die Bez. zw. Best. und Prod.) sowie "prod_cont" (Bez. Prod.-Cont.). Also insgesmt sind es jetzt 4 Haupt- und 4 Beziehungstabellen.

Was die Verteilung der Daten aus einem File heraus betrifft, habe ich schonmal mit "LOAD DATA INFILE" probiert doch ich muss den Umweg über PHP gehen.Nein, mir ging es eher darum, wie ich am günstigsten die Kontrollstrukturen aufbaue und in welcher optimalen Reihenfolge ich die Daten mit Insert in die Tabs schiebe...denn alles in eine Tabelle schaffe ich ja, inkl. Delete und Update.

So, ich werd erstmal wieder 'n bissl allein coden und denken ;-) Bei Fragen und Problemen werde ich aber gern auf Eure/Deine Hilfe zurückkommen.

Vielen Dank bis hier hin und viele Grüße
Steffen
__________________
Yesterdays, Todays, Tomorrows - Kicking off your sorrows!
Mit Zitat antworten
  #34  
Alt 12.09.2003, 11:28:57
diver-network diver-network ist offline
Junior Member
 
Registriert seit: Apr 2003
Ort: TÜ
Beiträge: 337
Hi Steffen,

als vorgeschlagene Reihenfolge der INSERTS:

zuerst füllst Du die Haupttabellen und, GANZ WICHTIG, gibst Dir mit mysql_insert_id() die ID des zuletzt angelegten Datensatzes aus. Diese speicherst Du, da Du diese in die Zwischentabellen einfügen mußt. Alternativ geht danach auch INSERT INTO tabelle SELECT... , wenn Du die letzte ID nicht speichern kannst.

Nochmal ein allgemeiner Tipp: Fang das Coden erst an, wenn die DB Struktur wirklich endgültig steht. Ansonsten hast Du immer Mehrarbeit.

HTH,

Andy
__________________
Delphine, Wale, Orcas und mee(h)r:
tauchen in Alor/Indonesien
http://www.alor-dive.com
Mit Zitat antworten
  #35  
Alt 12.09.2003, 11:50:19
Trialrider Trialrider ist offline
Anfänger
 
Registriert seit: May 2003
Ort: Oschatz/Sa.
Beiträge: 124
Jip, na dann werde ich mal (wieder) anfangen ;-)

Danke für den Tipp mit "mysql_insert_id()", Dann mache ich es bspw. so für die CSV-Daten:

Tu alles in "Shiplist", was dort hin soll. Gib mir dann die erzeugte ID als Var1 zurück. Packe alles in "Container", was da hin gehört und gib mir als Var2 diese ID wieder. Lege das"product" in selbiger Tabelle ab und melde die ID zurück

Packe Var1 und Var2 in "ship_cont" und Var2 und die product_ID in "prod_cont".

Wäre dies die Lösung des "Verteil-"problems? Würde es analog auf die Bestellungen und deren Zuordnung anwenden.

So, bleibt noch die Spalte "quantity". Kann ich die einfach in die Beziehungsspalte "prod_cont" mit reinpacken? Denn Container können ja auhc mal wieder angeliefert werden...

Und, die Produkte: empfiehlt es sihc da ein sep. Form zu basteln, in dem diese verwaltet werden und dann nur anderswo in ein SELECT-Feld gefüllt werden? Oder doch lieber eine Funktion, die schaut ob's dieses Product schon gibt und sonst anlegt =>geht glaub ich einfacher?

Besten Dank & MfG, Steffen

Ich hoffe, ich kann dir auch mal bei Problemen helfen...
__________________
Yesterdays, Todays, Tomorrows - Kicking off your sorrows!
Mit Zitat antworten
  #36  
Alt 12.09.2003, 13:49:12
diver-network diver-network ist offline
Junior Member
 
Registriert seit: Apr 2003
Ort: TÜ
Beiträge: 337
Hi Steffen,

<ZITAT>Packe Var1 und Var2 in "ship_cont" und Var2 und die product_ID in "prod_cont".</ZITAT>

Genau so.
Vielleicht noch einmal ein Hinweis bzw. eine Warnung zu mysql_insert_id(): Wenn Du ein Array in einer Schleife per SELECT in die DB schreibst mußt Du nach jedem INSERT den Befehl aufrufen und das Ergebnis in eine separate Variable (bzw. ein Array) reinschreiben. Außerdem darf die Verbindung zur DB zwischen dem INSERT und dem Befehl NICHT unterbrochen werden, z.b. mit mysql_close()!

Zu Deiner Frage mit "quantity": Das gehört in eine Zwischentabelle, entweder zwischen Container und Produkten oder Produkten und Bestellungen. Wo es besser passt mußt Du Dir überlegen, das hängt von den Anforderungen bzw. Gegebenheiten bei Dir ab. Wichtig ist aber, daß es nicht in eine der Haupttabellen kommt.

Zur Frage bzgl. Produkte:
Ich würde ein separates Formular zur Eingabe von Produkten anbieten. Diese kannst Du dann auslesen und z.B. als <option></option>- Liste in einem anderen Formular anbieten. Sollte ein Produkt in der DB fehlen kannst Du ja einen Link anbieten, der auf das Eingabeformular für Produkte verweist.
Was Du mit "eine Funkion..." meinst versteh ich nicht. Mit meinem Vorschlag mußt Du nur die ID des Produkts an Deine SQL- Befehle übergeben und nicht die Namen der Produkte. Daher kannst Du da nicht mehr überprüfen, ob es das Produkt schon in der DB gibt.

Aber auch hier gilt: Es gibt keine "beste" Lösung. Wenn Du es hinbekommst, daß automatisch geschaut wird, ob es das Produkt schon gibt und ansonsten das Produkt gegebenenfalls neu anlegt ist das für Deine Anwender sicherlich einfacher, aber für Dich schwerer programmierbar. Außerdem hast Du so das Problem, daß eventuell leichte Unterschiede in der Schreibweise des Produkts (GROß-kleinschreibung, Tippfehler etc.) zu redundanten Einträgen in der DB führen. Sprich: Man muß da ab und zu mal drüber schauen und die Daten eventuell anpassen. Das kann aber natürlich auch bei händischen Einträgen passieren, da fällt es aber eventuell schneller auf.

So, das war's für dies Woche von mir, das mit INT(3) vs INT(11) schau ich mir am WE mal daheim an und meld mich dann wieder.

Gruß und schönes WE,

Andy
__________________
Delphine, Wale, Orcas und mee(h)r:
tauchen in Alor/Indonesien
http://www.alor-dive.com
Mit Zitat antworten
  #37  
Alt 12.09.2003, 14:06:58
Trialrider Trialrider ist offline
Anfänger
 
Registriert seit: May 2003
Ort: Oschatz/Sa.
Beiträge: 124
Ich hoffe, dass ich das mit den Insert's so hinbekomme. Werde wohl auhc am WE daheim weitermachen.

Was die Strukturierung einer DB angeht, habe ich das nun endlich mal richtig verstanden. Man kann bekanntlich viel tot reden (vor allen in Schulen ;-)) doch bezogen auf meine DB habe ich es jetzt wenigstens anschaulich, was beachtet werden muss, wie man es am bessten angeht usw. Danke, Andy.

Für die Produkte schreibe ich dann doch in erster Linie ein "Modul", unter dem der User seinen "Mist" selber verwalten kann. Das mit der Funktion war halt so ein Gedanke, ihm den Tippkram abzunehmen.

Die "quantity" packe ich in die Beziehungstabelle "prod_cont".

So, ist auf alle Fälle genug Brot für ein ausgefülltes Wochenende.

Vielen Dank, und ebenfalls ein schönes sonniges WE.

Steffen
__________________
Yesterdays, Todays, Tomorrows - Kicking off your sorrows!
Mit Zitat antworten
  #38  
Alt 15.09.2003, 10:35:46
diver-network diver-network ist offline
Junior Member
 
Registriert seit: Apr 2003
Ort: TÜ
Beiträge: 337
Guten Morgen Steffen,

ich hab am Wochenende mal ein bisschen mit den INT() Datentypen getestet und, nachdem ich keinen Unterschied zwischen INT(3) und INT(11) gefunden habe jetzt endlich mal im Manual von MySQL nachgesehen (hätt ich ja auch gleich machen können).

<ZITAT>"Ein andere Erweiterung wird von MySQL unterstützt, um optional die Anzeigebreite eines Ganzzahlwerts in Klammern festzulegen, die auf das Basis-Schlüsselwort des Typs folgen (zum Beispiel INT(4)). Die optionale Breitenspezifizierung wird benutzt, um die Anzeige von Werten, deren Breite geringer ist als für die Spalte festgelegt, linksseitig mit Leerzeichen aufzufüllen. Das begrenzt allerdings nicht den Wertebereich, der in der Spalte gespeichert werden kann, noch die Anzahl von Ziffern, die bei Werten angezeigt werden, die die angegebene Breite für die Spalte überschreiten."</ZITAT>
<ZITAT>"Der Wertebereich einer INT-Spalte ist zum Beispiel -2147483648 bis 2147483647. Wenn Sie versuchen, -9999999999 in eine INT-Spalte einzufügen, wird der Wert auf den unteren Endpunkt des Bereichs abgeschnitten, und es wird -2147483648 gespeichert. Gleichermaßen wird beim Einfügen in eine solche Spalte nicht 9999999999, sondern 2147483647 gespeichert."</ZITAT>

Quelle: http://www.mysql.de/doc/de/Numeric_types.html

Kurz und gut, ich hab' mich bei meiner Aussage bzgl. der Datentypen und Wertebereiche getäuscht. Soll aber nicht wieder vorkommen ;-)

Gruß,

Andy
__________________
Delphine, Wale, Orcas und mee(h)r:
tauchen in Alor/Indonesien
http://www.alor-dive.com
Mit Zitat antworten
  #39  
Alt 17.09.2003, 10:51:26
Trialrider Trialrider ist offline
Anfänger
 
Registriert seit: May 2003
Ort: Oschatz/Sa.
Beiträge: 124
Moin Andy,

brauch mal bitte deine Hilfe, krieg sonst 'n Stich.... ;-)

[Vor reichlich 2,5 Std.]
Bei den Bestellungen habe ich das wichtigste vergessen: Pro Bestellung sind ja mehrere Positionen möglich. In meinen dyn. Formular dazu ist es ja auch so vorgesehen, doch die tabellarische Realisierung habe ich glatt vergessen.

[In der Gegenwart]
Nun sitze ich schon eine ganze WEile hier und versuche irgendwie sinnvoll Bestellung, dazugehörige Positionen und dann auch die Produkte miteinander auf'm Papier zu verbinden. Aber ich kriegs net hin.


Erstmal habe ich die _alte_ "bestellungen" etwas gelichtet. In "bestellungen" soll nur noch drinstehen: b_id, bestellung, durch, wann.

Bleibt für die "bestell_pos": bp_id, position, datum.

In "best_pos": id, b_id, bp_id (?)

Sollte ich was übersehen haben, weiß mich drauf hin. Wie und welche Tab(s) verbinde ich (mittels Beziehungstabelle) mit "products"? Egal wie ich es probiert habe, ich komme auf keinen grünen Zweig...

Deswegen Danke ich dir schonmal vorab für dein kompetente Hilfe.

Mit freundlichen Grüßen, Steffen

PS: Das mit den anderen Tabelle geht so, hoffe ich. Und, für die versch. Bearbeitungsmöglichkeiten mit Bestellungen (anlegen, ändern, zuordnen) verwende ich sep. Files. Die Erstellung des dyn. Formulars habe ich in eine Funktion ausgelagert, ebenso wie die verschiedenen SQL-Anweisungen.
__________________
Yesterdays, Todays, Tomorrows - Kicking off your sorrows!
Mit Zitat antworten
  #40  
Alt 17.09.2003, 12:21:03
diver-network diver-network ist offline
Junior Member
 
Registriert seit: Apr 2003
Ort: TÜ
Beiträge: 337
Hi Steffen,

nur nicht verzweifeln ;-)

Zu Deiner Frage bzgl. Verknüpfung von Bestellungen zu Produkten mein Vorschlag:

Tabelle Bestellungen:
- b_id
- durch
- wann

Tabelle Artikel:
- artikel_id
- name
- preis
- sonstige Infos zum Artikel

Tabelle Best_Art:
- id
- best_id
- artikel_id
- menge (des Artikels)
- preis (s.u.)

Tabelle best_cont:
- id
- best_id
- cont_id

Das müsste so klappen, überleg Dir aber in jedem Fall noch mal, ob Du so (möglichst) alle Fälle abdeckst und red mit Deinen KollegInnen, die sich in ER-Diagrammen auskennen. Außerdem hilft es auch, mit den Anwendern zu reden und die zu fragen, was denn alles so im Zusammenhang mit einer Bestellung vorkommen kann. Z.B. im Stil von: "Kann es sein, daß ein Artikel von verschiedenen Personen bestellt werden kann und eine Person verschiedene Artikel bestellen wird?" Die Antwort wird hier natürlich "ja" lauten, aber Du lernst daraus, daß zwischen Personen und Artikel eine Zwischentabelle gehört. Welche Daten da gespeicher werden müssen (z.B. der Preis) bekommst Du auch durch Fragen raus. Stichwort: "Gibt es Bestellungen, die ausgeliefert werden, aber noch nicht bezahlt wurden und kann sich dazwischen der Preis des Artikels ändern?" Auch da wird die Antwort "ja" lauten. Wenn Du jetzt den Preis NICHT in der Zwischentabelle speicherst bekommst Du ein Problem mit Deinem Kunden ;-)
Soviel zum Thema DB- Design, jetzt aber zu Deiner nächsten Frage:
Welche Tabellen Du ansonsten mit den Artikeln sinnvoll verbinden könntest weiß ich im Moment auch nicht. Normalerweise können Artikel doch nur im Kontext mit einer Bestellung vorkommen.

HTH und viel Glück,

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 16:30:41 Uhr.


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


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