Ich muss mich korrigieren. Statements zusammenzubauen ist nicht unbedingt eine Aufgabe für die Verbindungsklasse. Die Verbindungsklasse bekäme bei mir nur eine generische Query-Methode, also eine, die Query-String mit Platzhaltern und Array mit den Werten entgegennimmt, beides zusammenbaut (oder Prepared Statements dafür verwendet, wenn diese nicht so umständlich zu bedienen wären wie bei mysqli), die Query ausführt und das Ergebnis (z.B. als fertig abgefragtes Array) zurückliefert. Gegebenenfalls weitere zum Verbindung gehörende Dinge, wie erzeugte ID beim Insert, Anzahl der betroffenen Datensätze, doch das gehört eigentlich als Meta-Information mit ins Ergebnis. Weitere Methoden für die Verbindungsklasse könnten solche sein, die Meta-Informationen zum System ermitteln. Versionsnummer des Servers, Struktur von Tabellen (was für Tom), Werte von Konfigurationsparametern abfragen oder setzen. Das ist aber alles nur mehr oder weniger Schnickschnack, den du fürs Erste weglassen kannst.
Sprich sowas hier... [1]
»» function fetchObject($result){}
Eine intern benötigte Funktion bei der Erzeugung des Ergebnisses. Meine Idee der Query-Methode liefert bereits eine fertig abgefragte Ergebnismenge in Form eines Arrays mit je einem Array oder Objekt pro Datensatz. Wenn du das Fetchen den Verwendern überlässt, brauchst du keine eigene db-Klasse zu erstellen. Das gibt es fertig als mysqli-Extension. Um eine eigene Klasse zu rechtfertigen brauchst du irgendwelche Vorteile gegenüber dem Vorhandenen. Sich nicht um die Details des Fetch-Prozesses kümmern zu müssen, wäre ein Vorteil für die Verwender.
Hm aber die spalten heißen doch immer anders und sind unterschiedlich viel.. irgendwie blick ich nicht durch wie ich das realisieren soll..
Wenn die Funktionen die Verbindung bruachen ist das doch egal, es ist doch Singleton!?
»» function freeSQLresult($result){}
Gemäß meiner Vorstellung wird das Ergebnis ja von der Query-Methode komplett abgeholt, dort können dann auch die Result-Ressourcen aufgeräumt werden.
Das macht Sinn, danke.
»» function resultObject2array($object){}
Ein Parameter der Query-Methode könnte ein Flag sein, das angibt, ob du ein Array mit Objekten oder ein Array mit Arrays als Ergebnis haben möchtest.
S.o. ich weiß noch nicht genau wie ich das umsetzen soll.
»» function countEntries($table)(){}
Kannste streichen, geht mit count($ergebnisarray);
Die Funktion sollte eigendlich per "COUNT(spaltenname) AS anzahl" o.ä. fungieren.
Statements zu erstellen ist teilweise nicht schwer, für das üblichen UDI-Aufgaben. Auch ein Select-Statement ist für einfache Anwendungsfälle automatisch und mit geringem Aufwand erstellbar.
Siehe [1] ?
Doch SQL zeigt seine Stärken erst bei komplexeren Statements. Willst du diese automatisch zusammenbauen lassen, brauchst du bei geschachtelten AND-OR-verknüpften Bedingungen schonmal eine Strategie, wie man sowas als zu übergebenden Parameter einer PHP-Funktion gestaltet. Joins sind die nächste komplexe Stufe und Subselects, womöglich noch korreliert, machen die ganze Chose nicht einfacher. Und ein komplexes Statement immer wieder zusammenbauen zu lassen ist auch nicht gerade eine ressourcenschonende Angelegenheit.
Ein Kompromiss ist, RUDI-Statements-Ersteller für einfache Aufgaben zu verwenden und komplexe Abfragen (alles was über SELECT * FROM ... ORDER BY ... LIMIT ... hinausgeht) direkt zu formulieren.
Das hatte ich auch so vor, JOINS usw lasse ich nicht zusammenbauen..
»» Und in der Toolsklasse nützliche Funktionen wie:
»» function timestamp2Date(){}
»» function date2timestamp(){}
»» function compare_array_numbers($array_1,$array_2){}Was auch immer die letzte Methode genau machen soll ...
Zwei Arrays vergleichen ob Sie gleichgroß sind...(war für dynamisch erzeugte PS gedacht)...
alle drei sind DBMS-unabhängige Funktionalität. Das ist in einer Allgemeine-Tools-Klasse gut aufgehoben. Wobei allerdings MySQL Funktionen für das Umrechnen von Timestamps mitbringt (FROM_UNIXTIME() und UNIX_TIMESTAMP()). Wenn du also mit PHP Unix-Timestamps verarbeiten willst, dann kann MySQL die gleich so übergeben und übernehmen, entsprechende Funktionsaufrufe in der Query vorausgesetzt.
Gut das mit der Uhrzeit lässt sich auch direkt im Query erledigen.
lg, chris