nicht angemeldet
echo $begrüßung;
» Ich würde sie public nur mit den RUDI-Funktionen ausstatten, also Read (SELECT), Update, Delete und Insert. Wenn Bedarf in Sicht ist, kann sie immer noch erweitert werden.
Hm ich überlege gerade wie sollche Funktionen aussehen sollen, meinst du ne Methode die die Satements dynamisch erzeugt?
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.
» » 4.2 wie würdet ihr mit den beiden anderen Klassen verfahren?
[code lang=php]class db.ext{
function getLastInsertId($result){}
Dazu braucht es direkt die Verbindung. Ein Kandidat für die db-Klasse.
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.
function countFoundOrAffectedRows($result){}
Auch dazu brauchst du die Verbindung, kannst das also nicht auslagern. Ansonsten ist das Meta-Information zum Ergebnis, sollte also zu diesem dazugeliefert werden.
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.
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.
function countEntries($table)(){}
Kannste streichen, geht mit count($ergebnisarray);
function deleteTableEntries(){}
Ein Delete-Statement zusammenzubauen ist Teil der RUDI-Funktionalität.
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. 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.
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 ... 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.
echo "$verabschiedung $name";