SQLite

Was haltet ihr von SQLlite?
Mich würden eure Meinungen und Vorteile/Nachteile dazu interessieren.

Für kleinere Sachen ja, aber ich würde die Anwendungen schon von voraus so bauen dass sie mit recht wenig Aufwand auf eine "richtige" DB portierbbar sind, also z.B. die Funktionen kapseln. Man weiß schließlich nie wie groß die App mal wird

Im Prinzip benötigt man nur eine DB-Klasse. SQLite unterstützt die Standart-SQL Befehle. Von daher sollte eine portierung nicht das große Problem werden. Ich denke aber auch nicht umbedingt, dass es sich für größere Spiele eignet. Für klein Projekte oder Homepages, ist SQLite nicht schlecht.
Wobei die Datenbank an sich nichtmal so langsam ist: www.sqlite.org/cvstrac/wiki?p=SpeedComparison

Nun für ein kleines CMS mit meißt nur SELECTS sollte es reichen. Ist es sinnvoll eine Auswahl zwischen mehreren DB's zur Verfügung zu stellen, welche verwendet werden können (MySQL und SQLite, später auch noch Microsoft SQL)?

Tip: Sieh dir PDO an. Es lohnt sich und es so ziemlich egal welche Datenbank zu dahinter laufen hast.

Für kleine Sachen ist SQLite eigentlich ganz nett. Aber in meinen Augen ist es für den Entwicklungsprozess völlig ungeeignet. Die Bearbeitung von Tabellen ist stark eingeschränkt, so unterstützt der ALTER TABLE Befehl keine DROPS, was eventuell zu Problemen führen kann. Sollen Felder aus einer Tabelle entfallen, muss man die Tabelle komplett neu aufbauen und die Daten aus der alten Tabelle importieren. Auch kann man nachträglich keine CONSTRAINTS einfügen. UNd es gibt kein Rechtemanagment.

Original von progs
Wobei die Datenbank an sich nichtmal so langsam ist: www.sqlite.org/cvstrac/wiki?p=SpeedComparison

Richtig überraschend ist der Vergleich nicht, man muss ihn aber auch mit Vorsicht geniessen. Was der Vergleich aussagt ist, dass SQLite für einfache INSERT/SELECT Statements deutlich schneller ist. Das ist auch gut und richtig, hätte man aber auch ohne so ein Benchmark schon vorraussagen können. Systeme wie MySQL und Postgres "verschwenden" viel mehr Zeit um Transaktionssicherheit, Ausfallsicherheit (keine Tablecrashs wenn der Strom ausfällt), Parallelität etc.pp. zu gewährleisten. Ein einfaches System wie SQLite zieht da für einfache Abfragen natürlich davon. Oder, überspitzt ausgedrückt: wenn ich ein Script schreibe, dass 100.000 Zeilen in eine Datei schreibt ist das selbstverständlich schneller als wenn ich 100.000 Zeilen via MySQL oder Postgres in eine Tabelle schreibe...
Interessant sind z.B. Test 6 oder Test 15 wo man schon sieht, wo bei komplexeren Abfragen Systeme wie MySQL und Postgres langsam SQLite überflügeln.
Ein anderer wichtiger Punkt sind Konfiguration und datenbankspezifische Lösungen. Postgres hat oft in der Standardkonfiguration Geschwindigkeitsprobleme bei Tests wie "25.000 INSERTS ...". So wie die Konfiguration, die bei den Tests verwendet wurde ausschaut, war bei Postgres fsync aktiviert. Und dann überrascht es auch nicht mehr, dass Postgres bei diesen Abfragen deutlich langsamer wird, wenn für jede eingefügte Zeile ein fsync gemacht wird ...
Zum Anderen gibt es für solche Aufgaben oft datenbankspezifische Lösungen. Wenn ich bei Postgres eine Tabelle füllen will, dann benutze ich nicht 25.000 INSERT Statements sondern einen COPY Befehl. Und dann wirds gleich nochmal schneller, weil ich vor sowas auch fsync deaktiviere, Indexe droppe etc.pp. Bei MySQL könnte man z.B. Bulk Inserts verwenden.
Man muss sich immer überlegen, für was man das Datenbanksystem braucht. Wenn du einfach nur schnell ein paar SELECT/INSERT Statements auf überschaubaren Datenmengen absetzen willst, fährst du mit einer Datenbank wie SQLite deutlich besser, weil sich so ein System nicht mit dem Overhead, den Systeme wie MySQL und Postgres einführen, belastet (das ist z.B. auch der Grund, warum ein Test zwischen MySQL mit MyISAM Tabellen und PostgreSQL stets zu ungunsten von PostgreSQL ausfällt, weil MyISAM ein sehr simples Tabellenformat ist). Wenn du andererseits aber ein System brauchst, dass mit 100 oder 500 gleichzeitigen Lesern/Schreibern immernoch nicht zusammenbricht, gleichzeitig noch Transaktionssicherheit gewährleistet und dafür sorgt, dass die Tabellen nicht kaputt sind wenn die Fesplatte wegen einem Stromausfall den Geist aufgibt, und neben her noch Features wie Trigger, Checks, Rules etc.pp. anbietet, dann kommst du mit Postgres am weitesten.
Im Grunde ist das wie ein Vergleich zwischen einem Porsche und einem 100-Tonner. Klar, dass der Porsche trotz möglicherweise schwächerem Motor schneller ist. Dafür transportiert dir der Porsche aber auch keine 100 Tonnen Last.
Letzendlich sagt ein Test mit ein paar hintereinander abgefeuerten Statements nicht viel über die Datenbanksysteme aus. Geschwindigkeitstechnisch sind die alle gut optimiert. Interessanter wäre mal ein Vergleich, bei dem man parallel mit ein paar dutzend Lesern und Schreibern auf die Datenbank zugreift, bei dem jeder Leser/Schreiber auch noch ein dutzend Statemens pro Sekunde absetzt, und gleichzeitig Funktionen wie Trigger/Rules/Checks angestossen werden. Dann würden MySQL und Postgres einem SQLite davonziehen. Allerdings wäre der Vergleich genau so unfair wie der obige, da SQLite für so ein Szenario nicht gemacht ist. Genau wie MySQL und Postgres nicht für 25.000 INSERT Statements gemacht sind ...
Long story short: überlege dir, was du mit der Datenbank machen musst. Dann hast du eine Entscheidungsgrundlage. Ein generelles "SQLite ist besser als MySQL ist besser als PostgreSQL ist besser als Firebird ist besser als Oracle" gibt es nicht.

Was mich wundert ist, daß immer wieder versucht wird zwanghaft OpenSource Software einzusetzen.
Ich selbst habe Beruflich sehr gute Erfahrungen mit dem SQL-Server 2000/2005 gemacht und die Expressversion reicht für die meißten Browsergames locker aus. Oder man sieht sich von Oracle die freie Version an.
Mal ganz abgesehen davon, daß man hier auf so einen Unfug wie GPL und Co. einfach pfeifen kann und hier was die Zukunftssicherheit angeht nicht auf die Sprunghaften Launen der GPLer angewiesen ist.
Dadurch das die Expressversion ein Ableger der großen Version ist und diese Weltweit bei sehr vielen Firmen im Einsatz ist, kann auch eine Firma wie Microsoft nicht einfach beliebige Dinge ändern, wie es so oft bei OpenSource Sofware geschieht.
OT:
Ich gebe es zu kein Freund mehr von OpenSource Software zu sein. Dies hängt mit dem Verhalten der Kernelentwickler und der GPL v3.0 Fanatiker zusammen. Lieber wende ich mich Microsoft zu, als der Willkür und den Fanatismus der anderen Gruppierung ausgesetzt zu sein.

OT: PostgreSQL steht unter der BSD-Lizenz
Willkürliche Änderungen sind aber kein Problem der Softwarelizenz sondern der Herstellerpolitik. Wenn der der Meinung ist, willkürlich Änderungen einzuführen und damit seinen Kunden das Leben schwer macht ist das keine Lizenzfrage. Da hast du sogar bei OpenSource-Lizenzen den Vorteil, dass man das Projekt einfach Forken und mit einer vernünftigeren Politik weiterführen kann. Siehe z.B. XFree/X.org. Bei ClosedSource-Software bist du da gänzlich den Allüren des Herstellers ausgeliefert ...

Und unter uns... ich habe in über 10 Jahren weniger Ärger mit kommerziellen Lizenzen gehabt als in der gleichen Zeit mit OpenSource Sachen.
Wollte halt aufzeigen, daß es neben den OpenSource Datenbanken noch wirklich nutzbare und kostengünstige Lösungen gibt.

MrManco, kennst du den Inhalt der BSD-Lizenz? Ich habe bei deinen letzten Posting nämlich den Verdacht, dem ist nicht so. Deshalb hier die Lizenz in Deutsch und Englisch zum Nachlesen: de.wikipedia.org/wiki/BSD-Lizenz
Überhaupt sind BSD, MIT, GPL, LGPL und ähnliches sehr klar und verständlich formuliert. Und da nicht jedes Projekt eine eigene Lizenz hat (Bei Closed-Source die Regel) gibt es auch genug Anwälte die einen kostengünstig weiterhelfen können. Das Problem ist in der Regel nur, dass man sich auch daran halten muss. Die Tatsache, dass ein Programm als Quellcode vorliegt, verleitet immer wieder Leute, sie zu nutzen wie es einem beliebt.
Besonders bei der GPL ist dies aber praktisch unmöglich, wenn man sich an die Lizenz halten will. Weil man kann nur andere GPL-Programme gegen GPL-Bibliotheken linken. In diese Fall muss man wohl oder übel die Finger von diesen Programm lassen. Um Namen zu nennen: MySQL. PostgreSQL (BSD-Lizenz) ist aber eine ganz andere Geschichte.

BSD ist ja eigentlich keine Lizenz sondern eher ein "Mach damit was du willst"...

Die BSD-Lizenz ist mir schon geläufig, nur bin ich aus verschiedenen Gründen gegen jegliches OpenSource gefrickel. Das war mal komplett anderster in der Vergangenheit. Da war ich ein überzeugter Gegner von Microsoft und Co.
Mein Beruf hat es mit sich gebracht, daß mir Verlässlichkeit und die Einklagbarkeit von Vertragsklauseln aber wichtiger sind als solche Lizenzen.
Mag sein das ich zu viele Negative Erfahrungen gemacht habe und jetzt den gefürchteten Tunnelblick habe, aber ich gehe lieber auf Nummer sicher.

Wenn du auf solche Verträge pochst, kannst du immernoch zu den kommerziellen Anbietern von Opensource-Software gehen und da entsprechende Verträge abschliessen. Das geht bei MySQL, das geht auch bei PostgreSQL (Stichwort EnterpriseDB), das geht auch bei Linuxdistributoren. Es gibt überhaupt bei fast jeder halbwegs beliebten Opensource-Software jemanden der dafür kommerziellen Support anbietet.

Original von exeLong story short: überlege dir, was du mit der Datenbank machen musst. Dann hast du eine Entscheidungsgrundlage. Ein generelles "SQLite ist besser als MySQL ist besser als PostgreSQL ist besser als Firebird ist besser als Oracle" gibt es nicht.

Das ist genau der richtige Ansatz. Man muss sich ja nur mal ansehen, wofür ein bestimmtes DBMS entwickelt wurde und zwar bevor Sie für das Web entdeckt worden sind. MySQL mit MyISAM wurde z.B. für den Bereich Datawarehousing entwickelt, also für Read-Mostly-Anwendungen. MaxDB, auch bekannt als SAP DB, aus dem hause MySQL basiert hingegen auf ADABAS D und ist für den klassischen OLTP-Bereich entwickelt worden. Der Bereich in dem z.B. auch Oracle seinen Ursprung hat.
Oder nehmen wir dieses OO DBMS, welches an der Browsergame Conference vorgestellt wurde, komme gerade nicht auf den Namen. Das gute Stück wurde für den embedded Markt entwickelt, was natürlich eine ganz andere Anforderung erfüllt, als z.B. Poet, ebenfalls ein OO DBMS, was aber eher für große Shop-Lösungen entwickelt wurde.
Ein anderes schönes Beispiel bietet Oracle. Oracle unterstützt das aufteilen einer Db in Tablespaces, die man auf andere Devices auslagern kann. Damit eignet sich Oracle besonders gut für Datenbanken, die viel I/O Zugriffe verlangen und der Plattenzugriff den Flaschenhals darstellt. Dass ist natürlich eine andere Anforderung, als z.B. die Anforderungen an MS SQL.
SQLite spielt unter dieser Betrachtung eher im Bereich von Access, dBase und Paradox und ist eigentlich kein erwachsenes DBMS.
Man muss also gucken, was man braucht, für seinen Anwendungsfall.
Um TheHawk eine Antwort auf seine Frage zu liefern, ob es sinnvoll ist, eine Auswahl zwischen mehreren DB's zur Verfügung zu stellen, welche verwendet werden können: es hängt auch hier von der Anwendung ab. Im BG-Bereich halte ich das nicht für sinnvoll. Bei Anwendungen, die an Benutzer ausgeliefert werden hingegen sehr, vor allem, wenn man verschiedene Betriebsysteme und Lizenzen abdeckt. Ich kenne z.B. eine Buchhaltungssoftware, unter Windows, die standardmässig mit MS Access Datenbanken arbeitet. Allternativ kann man aber auch MS SQL oder MySQL nutzen. Damit sind alle Fälle abgedeckt: Man kann die Anwendung auf einem lokalen Rechner betreiben, ohne das weitere Software benötigt wird. Man kann eine MS Server Infrastruktur nutzen, sollte diese vorhanden sein. Oder man kann ein GPL Produkt, in Form von MySQL nutzen und unterstützt damit auch nicht-Windows Server. Die Anwendung selbst steht übrigens nicht unter der GPL, was auch nicht nötig ist, da die Anwendung kein festes Binding zu MySQL hat, und somit die GPL nicht zum tragen kommt.
Noch ein Wort zu den genannten Express-Versionen. Selbstverständlich sind das nutzbare DBMS. man muss sich nur darüber im klaren sein, welchen Einschränkungen diese unterliegen, egal ob es sich um die Version von Oracle, MS SQL oder IBM DB2 handelt. In einer der letzten IX Ausgaben war ein schöner Artikel darüber, aus dem auch hervorging, dass es diese Versionen nur Dank MySQL und Co. gibt.
Eine der Beschränkungen ist z.B. die Wahl des Betriebsystems. Leider ein Punkt, der immer noch nicht richtig beachtet wird. Aus meinem beruflichen Umfeld kann ich behaupten, dass die nicht Betriebssystem unabhängige Entwicklung von Anwendungen im KMU Umfeld sehr viel Ärger und Kosten verursacht. Nur mal ein Beispiel: eine Firma möchte ein DMS, ERP, CRM System einsetzen. Solche Anschaffung werden mit einer Soll-lebensdauer von 10 Jahren kalkuliert. Basiert das System aber auf propäritären Technologien, z.B. MS Produkte, ist nur eine Laufzeit von 3 Jahren sichergestellt. Fällt die Anwendung in den Bereich, in dem GDPdU und GoBS beachtet werden muss, hat man ein Problem. Dieses Gefahr lässt sich mit OpenSource Komponenten zwar nicht ausschliessen, aber minimieren.

Agmemon, ein sehr guter Beitrag. Also bei meinen Nebenbei-Projekt einen kleinen CMS werde ich einen Teil der DBMS-Systeme unterstützen bzw. auch die normalen Funktionen, wie auch die PDO-Driver zur Auswahl stehen lassen. Damit sich die Verbraucher nicht all zu sehr stehen gelassen fühlen wird es eine ausführlich Installationsanleitung geben, welche auch die Typen der DBMS bzw. zusätzlich PDO-Driver vorstellt. Was ist eigentlich der Unterschied in PHP zwischen den normalen DB-Connectoren (z.B. mysql_*, etc) und PDO? Gibt es bei PDO Geschwinigkeitsvorteile oder ist es einfach das OOP und die PDOExceptions für die Fehlerbehandlung?

Hawk, deine Benutzer werden es Dir danken. Mit PDO kenne ich mich nicht aus. Aber es ist zu erwarten, dass es etwas langsamer ist, als die normalen DB-Connectoren. Das ist eigentlich bei allen O/R-Mappern und Datenbankabstraktionsschichten, z.B. ADOdb für PHP/perl, nicht zu Verwechseln mit der gleichnamigen Technologie von MS, so.

Pro/Contra OpenSource-Datenbanken:
Wir haben vor 2,5 Jahren die Überlegung angestellt, welches Datenbanksystem einzusetzen ist, SQLite gabs damals noch nicht so wirklich.
Wir haben getestet:
Oracle 9
PostGres
MySQL (mit Transaktionen)
IBM DB2
MS SQL-Server
MaxDB
Gesamtranking grade in umgekehrter Reihenfolge.
Es ging hauptsächlich um das Managenement vergleichsweiser kleiner Datenmengen (aktuelle DB-Größe: 280 MB) bei einem ausgeglichenen Verhältnis von SELECTS und INSERT/UPDATES.
MS SQL-Server und Max-DB waren im Ranking gleichauf und weit vor den anderen. Die Entscheidung viel zu gunsten von MaxDB, wegen der Plattformunabhängigkeit (läuft aber schon immer auf Windows).
Ein bekannter von mir setzt SQLite embedded in seine Desktop-Anwendung ein. Von ihm höre ich eigentlich nur gutes.
Die mangelnde Tabellen-Manipulation (Constraints etc.) war ihm zu nervig, aber dafür kann man eben ein kleines Script basteln, das die Arbeit des "Neuanlegen / Kopieren / Umbenennen / alte löschen" übernimmt.

PDO ist langsamer, aber...
Es bietet einen komfortablen Zwischenlayer, welcher schon einigen Unfug abfängt den man sonst per Hand abfangen müßte. Beispielsweise die Prepared SQL-Statements. Ist eine feine Sache. Ok, hängt auch von der Implementierung der eigentlichen Schnittstelle zum DBS dann ab, ob dieses dies auch nutzen kann.
Der Hauptvorteil ist aber, daß man sich hier um die normalen SQL Sachen weniger Gedanken machen muß.
Die gängisten DBS werden hier schon unterstützt und man muß keine Sonderroutinen zu ihrer Erkennung einbauen. Wenn der Benutzer meint er müßte DBS A anstatt B nutzen.. soll er es.
Solange man keine DBS Spezifischen Statements verwendet, ist hier eine recht hoche Kompatibilität vorhanden.
Andererseits verliert man durch PDO natürlich auch ein wenig die Kontrolle über das Feintuning. Viele Dinge werden von PDO intern aufbereitet und man kann nicht mehr wie früher dann mit Dirty Tricks noch ein bissle Performance rauskitzeln.
Ok, es bleibt der Weg des Feintunings mittels Indizies und Co.
Andererseits stellt sich mir gerade bei Browsergames die Frage, wieso wir hier auf die bekannten DBS setzen.
Je nach Abfragetyp oder Verwendungszweck macht es durchaus Sinn die Daten in einem DataAccess Daemon zwischen zu lagern.
Dieser stellt z.B. über ein Interface Routinen für Get/Set zur Verfügung, mit denen man gezielter und schneller an die Daten kommt.
Ähnliches habe ich bei meinem vorherigen Projekt angefangen gehabt und bin damit sehr zufrieden gewesen.
Von einem anderen Programmierer weiß ich, daß hier für die Zukunft noch viel mehr Möglichkeiten geplant sind um sich mehr Performance zu erkaufen.
Ok, man muß die Abfragen dann in Code gießen, anstatt wie bisher hier ein SQL-Select zu erstellen.
Nur was ist teuer und knapper?
CPU-Power oder Hauptspeicher?
Dies ist auch wieder Projektabhängig. Das ist klar. Für die Zukunft sehe ich hier eher einen Mischbetrieb.
Reine Massendaten auf welche man eine hohe Zugriffsrate hat, sollten erst gar nicht von einem DBS verwaltet werden. Andere wie z.B. die täglichen Statistiken können durchaus in einem DBS liegen und in bestimmten Zyklen dann akkumuliert und aufbereitet werden.
Klar steigt durch so ein Vorhaben der Komplexitätsgrad um einige Faktoren und die möglichen Fehlerquellen sind auch mehr.
Nein, dies ist keine "Ich habe die perfekte Lösungs" Sache, sondern ein pragmatischer Ansatz für Performance Gewinne.
Um das Ganze ein bissle besser verstehen zu können, sollte man vielleicht mal einen Blick zurück werfen.
Zu Zeiten von 8-Bit Maschinen (C64/Atari XL) waren Datenbanken noch sehr unbekannt oder oftmals nur für die damals extrem teuren Hostsysteme vorhanden. Vieles steckte noch in den Kinderschuhen.
Auch war Speicher sehr knapp und CPU-Power ein kostbares Gut.
Viele der damals vorhandenen Techniken waren dadurch extrem Resourcensparend ausgelegt. Werft einfach mal einen Blick auf die sehr alten Systeme und versucht mal Gedanklich nachzuvollziehen, wie man mit so wenig, so viel machen konnte.
So... und zurück zum jetzigen Zeitpunkt
Stand heute gibt es sehr viele unterschiedle DBS.
Nebend den "normalen" DBS wie MySQL, SQL-Server 2000 und Co, gibt es noch die Objekt Orientierten DBS, welche bei entsprechender Programmierung einen enormen Performancegewinn versprechen.
Genau das erinnert mich an die alten (man möge es mir verzeihen) "Schwanzvergleiche" der Amiga-User mit den PC-Usern.
Die einen meinen das ihre Risk-CPUs (PowerPC und Co.) schneller sind, die anderen das die x86er CPUs schneller sind. Unter uns... in den x86er CPUs schlägt auch eine Art Risk-Kernel Keine Ahnung inwiefern sich da in den letzten Jahren was verändert hat. Ich sage nur a86 Gate *g* Tjajaja.. die alten Sündern...
Sorry... back to Topic... i know
Sinn und Zweck meines Textes ist und bleibt aufzuzeigen, daß es nicht DAS DBS oder DIE Lösung gibt.
Im Laufe eines Projektes verändern sich immer wieder die Anforderungen. Gerade im Bereich der Spieleprogrammierung kann man einfach nur bis zu einem bestimmten Punkt planen. Danach kommt das was man Blackbox nennt.
Im Bereich der Entwicklung von Anwendungssoftware, hat man eine klar definierte Aufgabenlage und der Kunde bekommt das was er bestellt hat. Kscht... nicht lachen... ich weiß doch selbst wie es ist Laßt mir mal die Illusion
Im Bereich Spieleprogrammierung kann ein DBS das Anfangs das am besten geeigneste das zum Ende hin sein, was die meißten Probleme und Umbauarbeiten zur Folge hat.
PDO hilft dabei einige (nicht alle) dieser Probleme zu umgehen. Ich sage nicht, daß die damit gelöst werden, sondern man umgeht sie nur.
Uff.. ich hoffe nicht zu viel Käse von mir gegeben zu haben.

Original von MrMarco
Andererseits stellt sich mir gerade bei Browsergames die Frage, wieso wir hier auf die bekannten DBS setzen.
Je nach Abfragetyp oder Verwendungszweck macht es durchaus Sinn die Daten in einem DataAccess Daemon zwischen zu lagern.
Dieser stellt z.B. über ein Interface Routinen für Get/Set zur Verfügung, mit denen man gezielter und schneller an die Daten kommt.

Das geht ja genau in die Richtung der Data Access Objects wie man sie in der Java-Welt gerne verwendet. Da passiert genau das: man definiert Interfaces die get/set Methoden für Daten zur Verfügung stellen. Für diese Interfaces kann man dann verschiedene Implementationen für unterschiedliche Datenquellen schreiben. Das funktioniert auch recht gut, da man für seine Daten recht genau definierte Zugriffsmethoden hat. Wenn ich z.B. eine Benutzerdatenbank habe sind die Zugriffsmethoden relativ klar: selektieren nach ID, Name, Login. Update nach Id. Löschen nach Id. Hierfür kann ich ein Data Access Object definieren:

interface UserDao extends Dao

{
public User retrieveById(int id);
public User retrieveByName(String name);
public user retrieveByLogin(String name, String password);
public void updateUser(User user);
public void deleteUser(User user);
}
Für diese DAO schreibe ich nun eine oder mehrere Implementationen. Im Regelfall eine für Zugriff auf eine Datenbank, eventuell auch über einen ORM/Persistenzlayer. Die Implementation wird von einem DaoManager bestimmt. D.h. man gibt das Interface an und der DaoManager spuckt die passende Instanz einer Implementation des Interfaces aus.
Der Vorteil an der Sache: man hat jeglichen datenquellenspezifischen Kram aus seinem Code raus. Keine Prepared Statements, kein SQL, auch keine Pseudosprachen wie HQL. Es folgt alles einer einheitlichen API. Daraus ergibt sich auch die Unabhängigkeit von Datenquellen. Man kann auf ein anderes DBMS wechseln, man kann auch verwendete ORM/Persistenzlayer austauschen. Man kann auch seine XML-Konfig über DAO zugänglich machen. Und wenn man irgendwann mal die Konfiguration doch lieber in der Datenbank speichert? Ganz egal, schreibt man halt eine andere Implementation des Konfig-DAO. Und wenn man am Anfang erstmal reines SQL in den DAO programmiert und später mal auf PDO/ADOdb o.ä. wechseln will hat das auch keine Auswirkungen auf den Rest vom Code ..
Darüber lässt sich dann auch ein Caching einfach realisieren. Ob das DAO das Rückgabeobjekt aus der Datenbank oder einem Cache zieht ist für den Rest der Anwendung unerheblich. Das sind Dinge die man im Nachhinein noch sehr bequem in die DAO einfummeln kann ohne den Rest des Codes zu tangieren.
Ist auf jedenfall keine blöde Sache und es funktioniert auch gut. Wird bei meinem Spiel auch so verwendet.

Im Prinzip muss jeder selber entscheiden, mit welcher DB er am besten zurechtkommt und welche für seine Zwecke am besten geeignet ist.

Kann man so ein DAO auch in irgendeiner Weiße in PHP umsetzen?

Natürlich, Data Access Objects bestehen ja nur aus Interfaces und Klassen. Das kann man in jeder Sprache umsetzen die Interfaces, Klassen und Objekte kennt.
Ein DaoManager ist ungefähr sowas:

class DaoManager

{
private $daos = array(
'UserDao' => 'SqlUserDao',
'XyzDao' => 'SqlXyzDao'
);
private $inst = array();
public function getDao($iface)
{
if(!isset($this->inst[$iface])) {
$this->inst[$iface] = new $this->daos[$iface]();
}
return $this->inst[$iface];
}
}
Und ein Dao nur
1. ein Interface

interface UserDao

{
public function getById($id);
public function getByLogin($name, $password);
}
2. mindestens 1 Implementation

class SqlUserDao implements UserDao

{
public function getById($id)
{
$res = mysql_query("SELECT * FROM users WHERE id = $id");
return $this->extractRes($res);
}
public function getByLogin($name, $password)
{
$res = mysql_query("SELECT * FROM users WHERE name = '$name' AND password = '$password'");
return $this->extractRes($res);
}
private function extractRes($res)
{
if(mysql_num_rows($res) != 1) {
return null;
}
$user = new User();
$row = mysql_fetch_assoc($res);
$user->id = $row['id'];
$user->name = $row['name'];
$user->password = $row['password'];
return $user;
}
}
Benutzung ist denkbar einfach:

// Irgendwo im Code

$userDao = $daoManager->getDao('UserDao');
$user = $userDao->getByLogin($_GET['name'], $_GET['password']);
if($user) {
echo "Du bist eingeloggt!";
} else {
echo "War nix ..";
}
Nur mal so als Pseudocode ...

Hey Danke, jetzt hab ich wieder was dazugelernt und kann meinen Code um einiges einfacher gestalten und verbessern. Und dank Dao gestaltet sich später ein Portierung des Games bzw. ein umdesignen der DB auch nicht mehr so schwer, da SQL-Statements nur mehr im Dao vorkommen.
Wo wird die Klasse User defniniert?

ich denke die Klasse user spielt bei seinem Code, der dir zu verstehen geben soll, wie man solche Schichten aufbaut, eher eine weniger interessante Rolle.
DAO sind meiner Meinung nach keine eingebaute Klassenbibliotehken, welche man nur in Java anfindet, sondern halt die Denkweise oder eben eine Strukturierungsart. (könnte man bei exes beitrag ein wenig missverstehen ) Dies wollte dir exe damit nun begreiflich machen Die Implementierung der Klasse User ist auch nicht vpn Nöten. Siehst ja ungefähr, wie sie auszusehen hat. Sie ist auch eben Anwendungspezifisch.
Sicher kann man auch ohne solche abstahierten Ebenen programmieren, aber es soll halt der Übersicht und vorallem auch dem Komfort dienen. Sehr lange Anweisungen, welche nur dazu dienen ein Datensatz aus einer bestehenden Datenquelle zu holen, machen die Hauptcode (also die darüberliegende Schicht) schlichtweg unübersichtlich.
Vorallem in Teamarbeiten ist diese Form der Programmierung (sicher gehen auch andere Modelle) sehr empfehlenswert, da man so eine Änderung der Datenbankstruktur (oder generell der Datenstruktur), dem anderen nicht erst erklären muss, sondern er sich einfach auf die vorhandenen Funktionen/Methoden hält. Am Anfang denkt man sicher, dass es Unmengen an mehr Aufwand bedeutet, weil man nun eigentlich 1000e (achtung übertreibung ^^) mehr ausskizzieren muss, damit man im Endeffekt einen doch recht lesbareren Code fabriziert.

Wo du die definierst bleibt dir überlassen. User ist ja nur eine Art Container für einen Datensatz vom Typ "User". So ein Container kann eine Klasse bzw. Objekt oder auch ein assoziatives Array sein. Es geht ja nur darum, dass du einen datenquellenunabhängigen Container für deine Datensätze hast. Würden deine DAOs einfach nur Resultsets einer bestimmten Datenbank zurückgeben, wäre die Funktionsfähigkeit auf diese Datenbank beschränkt und du könntest mit den DAOs keine Konfigurationsdateien, Webservices o.ä. mehr ansteuern (falls du das mal brauchst).
In Java benutzt man für sowas gerne Beans. Beans sind einfach nur Objekte die private Eigenschaften und für jede Eigenschaft öffentliche get/set Methoden haben. In PHP-Code sähe sowas folgendermaßen aus:

class User

{
private $id = 0;
private $name = '';
private $password = '';
public function getId()
{
return $this->id;
}
public function setId($id)
{
$this->id = $id;
}
// und für die anderen Eigenschaften genau so
}
Da PHP(5) dynamische Funktionen beherrscht, könntest du auch generische Getter/Setter schreiben (spart dir den Tippaufwand):

class User

{
private $id = 0;
private $name = '';
private $password = '';
public function __call($method, $parameters)
{
$what = substr($method, 0, 3);
$var = lcfirst(substr($method, 3));
if($what == 'set') {
$this->{$var} = $parameters[0];
} elseif($what == 'get') {
return $this->{$var};
}
}
Benutzen kannst du das Userobjekt dann folgendermaßen:

$user = $userDao->getById(5);

echo "Hallo ".$user->getName();
$user->setPassword("blubb");
echo "Dein Paswort wurde geändert";
Wenn du die magische __call Funktion benutzt, wird ein Aufruf auf getXyz oder setXyz auf die entsprechende Eigenschaft umgesetzt wenn diese Funktionen nicht explizit definiert waren.
Ich habe sowas schonmal benutzt. Dabei habe ich eine abstrakte Klasse mit diesem generischen Getter/Setter benutzt und jede "Modellklasse" (wie "User") von dieser Klasse abgeleitet um den generischen Getter/Setter zu vererben statt ihn überall via Copy&Paste einzufügen:

abstract class Model

{
public function __call($method, $parameters)
{
$what = substr($method, 0, 3);
$var = lcfirst(substr($method, 3));

if($what == 'set') {
$this->{$var} = $parameters[0];
} elseif($what == 'get') {
return $this->{$var};
}
}
}

class User extends Model

{
private $id = 0;
private $name = '';
private $password = '';
}
Trotzdem kannst du getter/setter später noch explizit einbauen, wenn du sie benötigst. Angenommen, ein User hat eine Anzahl X Planeten, du möchtest die Planeten aber nicht immer laden (weil sie nicht immer gebraucht werden). Dann kannst du sowas schreiben:

class User extends Model

{
private $id = 0;
private $name = '';
private $password = '';
private $planets = array();
// Lazy loader für planets
public getPlanets()
{
if(count($this->planets) == 0) {
$daoManager = DaoManager::instance();
$planetDao = $daoManager->getDao("PlanetDao");
$this->planets = $planetDao->getUserPlanets($this->id);
}
return $this->planets;
}
}
In dem Fall werden die Planeten transparent nachgeladen, wenn sie benötigt aber initial nicht geladen wurden. Daran sieht man auch wieder inwiefern es Sinn machen kann Objekte zum kappseln von Funktionen und Daten zu verwenden.

Ich verstehe den Post von MrMarco nicht, der die Diskussion in Richtung DAO gebracht hat. PDO ist doch eine DAO Implementierung, genauso wie JDO und Enterprice Beans in Java und ActiveRecords und Rails.
Hinter jedem O/R-Mapping steckt das DAO Prinzip, wird nur unterschiedliche implementiert. Aber ein DBMS steckt immer dahinter, egal ob jetzt relational, objektorientiert oder xml-basierend. Irgendwie muss ja auch die Persistenz gesichert sind. Und die Zeit der Flatfiles ist ja zum Glück so gut wie vorbei.
Zum Thema Performance gibt es aber noch eine schöne Sache zu sagen, da MrMarco ja in Richtung Datenhaltung im Speicher geschielt hat. memcached lautet das Zauberwort und hilft so mancher Webanwendung gehörig auf die Sprünge.

Man möge es mir verzeihen, daß ich in meinem Posting gestern ein bissle verwirrend gewesen bin.
Aber die Diskussion zeigt mir, daß die Botschaft angekommen ist.

Vielleicht kann man das Thema ja teilen

achja es gibt auch ne php alternative, welche sich adodb schimpft. sicher das gleiche nur halt anders genannt. ich kenn mich zwar nicht damit aus, soll aber laut informativen silvesterquellen das gleiche bewirken
Tutorial:
phplens.com/phpeverywhere/adodb_german

Eine Anmerkung noch zu SQLite: Ich hab SQLite als es fester Bestandteil von PHP wurde mal angetestet und zu dem Zeitpunkt hatte die DB einen riesigen Nachteil - einmal angelegte Tabellen konnten nicht mehr verändert werden. Es gab keinen "ALTER TABLE ...".
Ich weiß nicht, ob das immernoch so ist, aber wer ernsthaft den Einsatz von SQLite erwägt, sollte das vorher unbedingt prüfen.
Ciao,
Marc

Habs nicht getestet, aber so wies ausschaut funktioniert das jetzt: sqlite.org/lang_altertable.html