Ich fürchte wenn du das allen sagst die vor 5 Jahren versucht haben jemandem nach bestem Wissen und Gewissen zu helfen, wirst du sehr viel zu tun haben
Das Posting ist wirklich ein bisschen zu alt und das google Ergebnis bei Hilfesuche von 2005 sah sicherlich anders aus als das heutige

---

Huch.

Da hast du natürlich Recht. Habe leider nicht auf das Datum geachtet.. ;)

Aber du wirst lachen: Ich habe bei meiner Recherche zu diesem Beitrag gefunden. Ergo finden ihn auch andere. Somit finde ich die Richtigstellung für unerfahrene Entwickler nicht unwichtig.

Aber gerade, weil du dich ja auch zu Wort meldest: Kannst du nicht etwas kreatives dazu beitragen? Mir selbst hat das alles leider nicht viel gebracht. Muss noch immer die Smileys umständlich per externer Datei includen und replacen :( Denn ich will meine Smileys via Datenbank zusammenstellen. Also, dass die Codes und Dateiverknüpfungen in der entsprechenden Tabelle stehen und ausgelesen und entsprechend ersetzt werden. Mein Problem ist der Aufbau oder besser das Füllen des Such- und Ersetzarrays über die DB.

Dankeschön. ;)

Wenn ich könnte, würde ich. Aber ich bin ein schrecklicher Code Schnippsler und kann so rein gar nicht dabei helfen, nicht einmal laienhaftes Wissen könnte ich beisteuern.

Wenn du Fragen zu Domains , Providerwechseln hast, dein Postfach Fehler spuckt oder sich Wordpress nicht installieren lassen will, dann kann ich gerne helfen, aber mit direktem Coding kann ich gar nicht dienen

---

DerDaddy schrieb am 09.03.2010 11:48 Hi... Ehe du dir etwas Falsches bezüglich str_replace() erzählen lässt: Der Aufbau mit str_replace() sieht folgendermaßen aus: str_replace($WAS_STRING, $MIT_WAS_STRING, $WO_STRING) Heißt also, wenn du den ; - ) durch ersetzen willst, sieht das so aus: echo "Hier folgt nun der Text: ".str_replace('; - )', '', $text)." So einfach ist das Ganze." Die Antworten der anderen Poster waren schon ganz richtig, aber der Aufbau der Funktion in der Reihenfolge leider verkehrt. Der DBText wird IMMER als letzter Parameter angegeben. Hier kannst du das Ganze auch nochmal selbst nachlesen: http://de2.php.net/manual/de/function.str-replace.php An alle Helfer: Ich vermute, ihr seid mindestens fortgeschrittene PHP-Developer. Ergo solltet ihr die Funktion auch vom Aufbau her kennen. *lieb sag* Es nützt leider nichts, wenn ihr hier Halbwissen weitergebt. Wenn ihr euch selbst nicht sicher seid, dann verweist auf diverse Manuals, die es ja zu Hauf gibt. *zwinker* Ich selbst bin irgendwo zwischen Anfänger und Fortgeschrittener und bin somit auch auf richtige Antworten/Gedankenansätze angewiesen. Besonders wichtig ist es, wenn man eine Funktion überhaupt nicht kennt und sie mit eurer halbwissentlichen Antwort nutzt und es zu Fehlern kommt. Den Fragenden sage ich aber auch, dass ihr einfach mal in der PHP-Manual nachlesen solltet.

Das ist nicht ganz korrekt. Wie du schon richtig sagtest: RTFM. Die Funktion kann für die beiden ersten Parameter auch Arrays annehmen bzw. für den ersten ein Array und für den zweiten einen String.
Bei ersterer Version wird paarweise ersetzt. Bei der zweiten werden alle Fundstellen der Array-Elemente durch den String ersetzt.

Ebenso kann der 3. Parameter auch ein Array sein. Dann wird für jeden String im Array ersetzt.

Also bevor man groß rumposaunt lieber selber erstmal lesen.

Das mit der DB ist eigentlich relativ einfach. Werde wenn ich wieder Zeit habe mal die Grundidee erklären.

---

Hi chip,

du hast natürlich recht. Man kann anstelle des Strings auch ein Array nehmen, für Anfänger ist der String aber einfacher zu handhaben. Ich selbst arbeite auch mit Arrays. Nur eben nicht mit dem Inhalt der DB gefüllt, sondern schön selbst alles in die Arrays von Hand eingetragen. ;) Nur ist das für mich weniger komfortabel.

Auch sind mir die Aufbauten von Arrays bekannt. Ich habe schon einiges versucht, die beiden Arrays mit den Daten der DB-Tabelle so aufzufüllen, dass die Suche entsprechend mit dem Ersatz verglichen und ersetzt wird.

Ich bin auf deine Erklärung der Grundidee sehr gespannt.. ;)

Bis demnächst

OK. Zum Aufbau der Tabelle: Die Tabelle sollte folgendes Schema besitzen

search | replace

search ist hier der Primärschlüssel. Es kann zusätzlich auch noch ein ID-Feld angelegt werden, welches dann einziger Primärschlüssel ist. Dann sollte aber wegen der Zugriffsgeschwindigkeit ein Index auf search gelegt werden. Beide Felder sollten vom Typ VARCHAR sein (bzw. wenn das ID-Feld hinzukommt dafür dann INT).

Nun werden also die Paare von search-replace in die Tabelle eingetragen, beispielsweise:



etc, etc.

// EDIT: Leerzeichen bei den Smileys eingefügt, weil sonst die Smiley-Ersetzung hier im Forum spinnt.

Ich nehme einfach mal an, dass du mit den grundlegenden Abläufen für eine DB-Abfrage (speziell MySQL) in PHP vertraut bist. Daher nur die entscheidenden Stellen:



Ebenso wäre es auch möglich mit der String-Translate-Funktion strtr() zu arbeiten. Aber hier genau auf den Abschnitt in der Manual achten!

strtr() kann auch mit nur zwei Argumenten aufgerufen werden. Wenn der Aufruf mit zwei Argumenten durchgeführt wird, verhält sich die Funktion anders: from muss nun ein Array sein, das string -> string-Paare enthält, die im Originalstring ersetzt werden sollen. strtr() tauscht dabei zuerst die längsten möglichen Treffer aus und verändert bereits durchgeführte Ersetzungen *NICHT*.

Der Code würde dann so aussehen:



Eine andere (effizientere) Möglichkeit die Tupel aus der DB zu lesen und dann in das Array (die Arrays) zu packen gibt es IMHO nicht (mal von kleinen Verbesserungen abgesehen). Generell ist es besser so wenig wie möglich DB-Abfragen zu haben und PHP mehr Arbeit machen zu lassen. Am besten mit eingebauten Funktionen weil diese durch ihre Implementation in C deutlich schneller sind als benutzerdefinierte Funktionen.

Ich hoffe ich konnte dir damit ein wenig behilflich sein oder deinen bisherigen Ansatz bestätigen.

(Hinweis: Code nicht getestet -> Vertipper nicht ausgeschlossen ).

---

Hey.

Danke für deinen Ansatz.. Werde es mal probieren.

Meine DB baute ich bisher so auf:

id | search | replace

Wie ich sehe, liest du die Tabelle mit _assoc aus. Ich bin eher der Freund von _object. Vielleicht lag darin mein fehlerhafter Arrayaufbau.

Ich danke dir erstmal und werde mich dann später zu deinem Vorschlag erneut äußern. ;)

Ich persönlich bevorzuge mysql_fetch_object() dort, wo Objekte angebracht sind (Stichwort: OOP). Beispielsweise beim sogenannten Model-View-Controller-Modell (MVC). Dort kann man gut ein Model als Objekt definieren und dann schön die Eigenschaften direkt in das Objekt schreiben per mysql_fetch_object(). Der Code würde auch für mysql_fetch_object() gehen. Dazu musst du folgendes ändern:



---

chip schrieb am 13.03.2010 11:55 Generell ist es besser so wenig wie möglich DB-Abfragen zu haben und PHP mehr Arbeit machen zu lassen.

Kann man so absolut nicht stehen lassen. Grundsätzlich gilt:
Was schon mit dem DB-srv abgearbeitet werden kann (e.g. Berechnungen, Stringfunctionen, etc.), sollte auch mit diesem erledigt werden.

Mit der Anfrageanzahl gehe ich mit - so gering wie möglich. (Aber wozu gibts Joins, Subselects...)

---

Wer andern eine Grube gräbt,
sollte darüber nachdenken,
ob sie tief genug ist!!!!

Kameradschaft ist, wenn der
Kamerad schafft !!!!

raiserle schrieb am 05.04.2010 14:35 Kann man so absolut nicht stehen lassen. Grundsätzlich gilt: Was schon mit dem DB-srv abgearbeitet werden kann (e.g. Berechnungen, Stringfunctionen, etc.), sollte auch mit diesem erledigt werden. Mit der Anfrageanzahl gehe ich mit - so gering wie möglich. (Aber wozu gibts Joins, Subselects...)

Nein, kann ICH leider nicht so stehen lassen .

Joins und Subselects sind teuer (kosten viel Zeit, Rechenleistung und Speicher, weil meist alle Tupel ausgelesen werden müssen, dann Kreuzprodukt und Selektion). Besser ist es in diesem Fall mehrere kleine Anfragen zu haben.
Berechnungen, etc. würde ich nur bedingt dem DB-System überlassen, weil auch diese meist langsamer sind, als die nativen PHP-Funktionen.
Es ist also alles immer eine Einzelfallabwägung.

---

Aha:

Chip, sorry. Nein dem ist nicht so.
A) Gibt es Optimierer, die bei Subselects (Joins) ziehen.
B) Wird niemals ein komplettes "Kartesiche Produkt" gebildet
C) Ist der DB-srv sehrwohl schneller als die "Interpretersprache" PHP.


und
D) auch mal über den Tellerrand gucken. Es gibt ja nicht nur MySQL - was mit Berechnungen nicht sehr optimal umgeht - zugegeben.

Es geht hier um deinen Grundsatz: Lieber das "Backend" die Arbeit machen lassen - als das "RDBMS".
Und dem kann ich als Grundsatz NICHT zustimmen.

Gruß raiserle

---

Wer andern eine Grube gräbt,
sollte darüber nachdenken,
ob sie tief genug ist!!!!

Kameradschaft ist, wenn der
Kamerad schafft !!!!

OK, zugegeben ist MySQL sicher nicht optimal, hat aber genauso seine Schwächen wie andere Systeme (PostgreSQL, etc.)

Optimierer sind natürlich immer im Spiel, können aber nur innerhalb ihrer Grenzen die Query optimieren (Selektionen & Projektionen vorziehen, usw.). Ob ein komplettes kartesisches Produkt gebildet werden muss, hängt von der Abfrage ab (und das kommt durchaus häufiger vor). Unter kartesischem Produkt verstehe ich hier auch im weitesten Sinne, wenn alle Tupel ausgelesen werden müssen (also von vorherigen Projektionen mal abgesehen). Und die sind sehr wohl teuer.

Der DB-Server mag schneller sein, als die Interpretersprache, aber die Anbindung an eben diesen Server ist der Knackpunkt (egal welches DBMS). Es dauert eben, bis der Interpretersprache alle Daten vom DBMS zur Verfügung stehen. Genau hier sollte man sich gut überlegen, wem man die "Arbeit" überlässt.

Was die Performance der Berechnungen angeht kann PHP schneller sein, weil die Funktionen auf C-Bibliotheken aufsetzen, die einen Geschwindigkeitsvorteil bieten (aber in engen Grenzen, da gebe ich dir vollkommen Recht). Wenn man schon eine Query ausführt, kann man meistens die Berechnungen auch vom DBMS erledigen lassen, da hast Du recht.

Ich stehe zu dem Grundsatz, die DB-Abfragen auf das nötigste zu begrenzen (da gibst du mir sicher Recht) und lieber etwas mehr Arbeit an PHP abzugeben. Natürlich nicht immer, weil man von Fall zu Fall abwägen muss. Es hängt auch stark von der Komplexität der Queries und "Aufgaben" ab.

---

Ok - gut, so kann man das stehen lassen.
Mir missfiel eben nur der Grundsatzgedanke (Generell) in deinem Post.

Zugegeben: Man muss in den einzelnen Fällen "Benchmarks" machen.

Ich kann nur soviel dazu sagen, dass ich SQL-Statemenst schreibe, die auch mal mehr als 2 A4-seiten füllen. Um das selbige Ergebnis in PHP zu konstuieren, müssten mehere Schleifchen und ne Menge
IF-Else herhalten. Da habe ich schon mal eher das Gefühl, dass ich es lieber das (R)DBMS :D machen lasse.

lG raiserle

---

Wer andern eine Grube gräbt,
sollte darüber nachdenken,
ob sie tief genug ist!!!!

Kameradschaft ist, wenn der
Kamerad schafft !!!!