PDO oder MYSQLi oder andere

Hi leute,

ich will mal hier in der runde fragen , welche der DataBase Exensions besser geeignet wäre für ein BG?

Habe mich durchgegoogled von PDO über MYSQLi bis nach Zend DB. Alles scheint gut und schön zu sein nun stehe ich vor der Wahl was ich am besten nehmen sollte. was mir wichtig wäre :

• Die Extension sollte oop sein
• SQL Injection vermeiden(pripared statements)
• Datenbank unbhängig sein(Also nicht nur Mysql sondern auch Oracle oder MSSql etc)
• Einfache umstellung(Damit ich nicht zu viel im quellcode verändern muss)
• Inhalte direkt im utf8 format abspeichern (ohne dass ich davor utf8_encode() verwenden muss)
• Multiquerys(kann ja irgendwann sein dass man die benötig)
• Schnelle ausführung und geringer Ressourcenverbrauch

Ihr kennt euch da sicher besser aus als ich und könnt mir bestimmt ein paar tipps geben

MFG

BlackScorp

Du suchst eine Datenbankabstraktion wenn ich dich richtig verstehe:

Zend_Db kann sowohl mit PDO- als auch mit MySQLi-Adaptern arbeiten.

Es gibt viele Leute die auf Doctrine schwören.. ich kann dazu nichts sagen, weil ich es noch nicht benutzt habe.

IMHO machst du dir zuviele Sorgen um nichts

1.2.3.4

auch mit mysql_ lassen sich sich schöne und performante anwendungen schreiben. den DB-Handler hast du beretis mehr oder weniger fertig. Damit liessen sich die  SQL-Injections schon sicher minimieren/beseitigen. OOP Zugriff und Kapselung ist auch da (Punkte 3 und  4) PreparedStatements sind in PHP ohne StoredProcedures nur ein nutzloser Begriff (in Java ist es anders)

5. Mit UTF-8 hast du dir vermutlich selbst ins Bein geschossen. Wenn man die Tabellen/Spaltencollation sowie die PHP sourcen / HTML-Codierung auf  UTF-8 auslegt, muss man utf8_encode() nie im leben verwenden

6. Multiquery? Wie oft brauchst du da? und für einmal im Monat reicht auch knackige STORED ROUTINE

7. die beste DB-Schnittstelle ist nix wert, wenn die Datenbankarchitektur sowie die abgefeuerten Queries  MÜLL sind

eigentlich haste recht ich könnte meinen DB handler locker verwenden mich hat es halt etwas stutzig gemacht wegen dem eine thread hier im forum wo oracle mysql aufkauft. ich mein man kann nie auf sowas vorbereitet sein und man sollte am besten schnell umspringen können. mein DB handler ist zudem nicht sicher genug gegen sql injections (wie du es sagst) und befor ich da weiterprogrammiere dachte ich wozu das rad neu erfinden. also je weiter ich lese und google finde ich PDO immer mehr sympatischer. punk 5 und punkt 6 kann man wirklich weglassen. und diese aussage verstehe ich nicht:

PreparedStatements sind in PHP ohne StoredProcedures nur ein nutzloser Begriff

könnteste das etwas erlautern?

MFG

du hast prepared statements(PS)  in php als mittel gegen injection angeführt, IMHO  hat PS in PHP nicht denselben stellenwert wie in Java. eine sichere query lässt sich in PHP auch ohne PS bauen, du solltest dir sowieso angewöhnen die User/REQUEST-eingaben  vorab zu validieren und ales unerwünschte garnicht erst an die DB übergeben.

Ich verstehe deine bedenken, allerdings sehe ich im zusammenhang mit dem eigentlichen (BG?)Entwicklungsprozess eher pragmatisch. Was nützt mir endlose Sicherheitsdiskussion wenn mein eigentliches Spiel kein Stück vorankommt. Tatsache ist, dass du bisher noch nicht soviele komplexe Web-Anwendungen geschrieben hastund egal wie du es anstellst, es wird dir nicht gelingen von Anfang an alles richtig zu machen - zuviele Faktoren gehören dazu, als dass man die in deiner Situation alle erfassen kann (nicht als Kritik  zu verstehen).  Es ist wunderbar, dass du dir Gedanken machst, das gehört dazu, aber man kann auch übertreiben

naja dass ich nicht vorankomme liegt an den ganzen neuen sachen die man während einer entwicklung entdeckt.ständig komme ich auf neue einsichten und veränder quellcode und dann lauft nichts mehr und dann fange ich von vorne an usw usw... die ganzen sicherheitsbedenken die ich habe , kommen von einer nicht so schönen erfahrung als jemand bei meiner page folgendes in der url aufgerufen hat:

index.php?search=userx;'+UPDATE+users+SET+rights+=+admin+WHERE+id+=+x

und dann alles gelöscht hat:D seid dem beschäftige ich mich damit. aber ich denke du hast recht in allem recht. wird langsam zeit sich an das spiel zu wagen und alle fehler im nachinein zu elemenieren

MFG

Original von BlackScorp
naja dass ich nicht vorankomme liegt an den ganzen neuen sachen die man während einer entwicklung entdeckt.ständig komme ich auf neue einsichten und veränder quellcode...

Oh ja das kenne ich auch ^^.

Trotzdem: Das Thema 'Datenbankabstraktion' (und das drumherum) ist wohl das wichtigste und es ist schon gut dass du dir darüber Gedanken machst. Ich jedenfalls würde nicht mehr einfach nur mit mysql_-Befehlen arbeiten wollen...

Hier mal ein paar Schlagworte für dich zum weiterrecherchieren:

AdoDb, PEAR-DB, Zend_Db, Zend_Db_Table, ORM, Table Data Gateway, Row Data Gateway, Active Record

>wird langsam zeit sich an das spiel zu wagen und alle fehler im nachinein zu elemenieren

Ich weiß nicht. Ich musste feststellen, dass ich ähnlich wie du oft Code ändere aufgrund meines Lernfortschritts. Die Entwicklung wird dadurch natürlich enorm verlangsamt, aber dein Lernprozess profitiert extrem. Anfangs schrieb ich noch an bestehendem Code, mittlerweile habe ich in PHP ein für Java übliches Klassengerüst, das wie ich gehört habe nur wenige PHP Browsergames haben. Bei mir ist noch lange nichts fertig, aber ich lerne immer mehr und bringe auch meine neuesten Erfahrungen mit ein. So schreibe ich mittlerweile große Teile in JavaScript clientseitig, aber auch OOP.

Solltest du zu dem Schluss kommen, dass du dein Spiel auch objektorientiert schreiben willst und nicht wie meist mit PHP prozedural, dann mach dich darauf gefasst, dass du sehr viel lernen musst und die Entwicklung ersteinmal für einige Zeit still liegt.

Original von tector

AdoDb, PEAR-DB, Zend_Db, Zend_Db_Table, ORM, Table Data Gateway, Row Data Gateway, Active Record

danke werd mich mal durchgoogeln:D

@ Phoscur

naja ich schreibe mein BG OOP in PHP und das hat mich ganz schön aufgehalten in der entwicklung

Auch wichtig bei DB-Abstraktionen:

Falls man SQL schreibt sollte man tunlichst ANSI-SQL schreiben (also das standardisierte) und von z.b. mysql-konstruktionen wie

select if(foo,1,0); from bar;

das standard konforme

select case foo = 1 then 1 else 0 end from bar;

nehmen.

Dann sollte es auch weniger probleme geben, falls man die Datenbank doch mal wechseln muss.

Und noch ein genereller tipp: Sieh dir mal InnoDB in MySQL an.. das ist wohl eher was du brauchst, da du auch sehr viele schreiboperationen haben wirst und so die table-locks von MyISAM echt tödlich werden können.

Auch geh ich davon aus, dass du von Transaktionen und Nebenläufigkeit recht wenig gehört haben wirst - informier dich dahingehend auch, bevor du viel zu grobe schnitzer machst.. :D

Ich persönlich verzichte lieber auf eine DB-Abstraktion (pdo nutze ich noch, da es einiges vereinheitlicht). Ich hab es lieber, wenn ich das SQL selbst schreibe und in abstrakte Klassen auslagern kann.

Im Code hab ich dann nur noch ein Gebäude::bau(planet, user, gebäude); und die methode weiss dann schon, was sie in die db zu schreiben hat. Das trennt die Logik etwas besser von der Datenbank... aber ich schweife ab .. :D

meine datenbank ist sowieso vom typ InnoDb weil MyIsam keine primärschlüssel unterstützt(soweit ich das mitgebkommen habe)

Transaktionen?

und Nebenläufigkeit?

kurzer blick über google sagt mir dass ich schon mal davon gehört habe in meiner ausbildung. es geht nicht um die datenbank selbst und wie ich sie anspreche sondern rein um die sicherheit. habe 3 jahre ausbildung als Wirtschaftsinformatiker hintermir und jetzt im 2en jahr als Anwendungsentwickler also 5 jahre sich mit datenbanken beschäftig. und ehrlich gesagt bin ich ganz deiner meinung wegen SQL selber schreiben desswegen nutze ich immer noch die standt befehle wie mysql_query() oder mysql_fetch_array(). und diese

select if(foo,1,0); from bar;

art querys zu schreiben kenne ich garnicht:D

naja ich werd dann mal weiter programmieren danke für eure hilfe

MFG

Imho die beste Erklärung für Nebenläufigkeit

http://www.virtualmachine.de/2000-ernst-schneider/node21.html

Transaktionen ist vielleicht zu allgemein

( http://de.wikipedia.org/wiki/Transaktion_(Informatik) )

Interessanter wäre schon der Punkt Transaktionssicherheit :)

Wenn du experimentierfreudig bist und PHP 5.3 nicht scheust: http://www.derivante.com/2009/05/19/php-activerecord-available-for-beta-testing/

Mit 5.3 kommen viele features, z.b. statische magic methods, die das ORM Leben in PHP angenehmer machen.

PHP 3.5 und Firefox 5.3, (pardon natürlich andes herum) sind jetzt da.

> Mit 5.3 kommen viele features, z.b. statische magic methods

UTF-8?

Ein guter Programmierer braucht nicht mehr als 8 bitse für ein Zeichen !

Original von buhrmi

Ein guter Programmierer braucht nicht mehr als 8 bitse für ein Zeichen !

Glaubst du! Mit der Vielfahlt der kyrillischen, chinesischen, japanischen, indischen und nicht zuletzt arabischen Zeichen lässt sich wesentlich kompakterer Code verpacken. Darüber hinaus kann man sich jede Dokumentation sparen, wenn in jedem Zeichen bereits alles erklärt ist.

Ha. Jetzt bleibt dir die Spucke weg.

Wer liest diesen Multinationalen Code dann? Wer lernt alle Vokabeln um das zu verstehen? Ein Computer? Aber dann schreiben wir Programmierer doch wieder unser "Logik-Englisch"...

> Aber dann schreiben wir Programmierer doch wieder unser "Logik-Englisch"...

Ich durfte schonmal Quellcode mit japanischen Variablen überprüfen...

War sehr schön!

Englisch ist nicht die Mutter aller Sprachen. Habt Respekt vor anderen Nationen und Kulturen, nicht jeder möchte eingeenglischt werden.

BTW: Ich persönlich programmiere in Englisch und würde bei meinem nächsten PHP-Projekt PDO nutzen.

Hm.. ich habe mal PDO ausprobiert. aber irgendwie stürzt apache ab sobald ich eine query ausführe

PHP:

$conn = new PDO('mysql:host='.Defines::$dataBaseServer.';dbname='.Defines::$dataBase.'', Defines::$userName, Defines::$userPassword);
        
$query = $conn->prepare('SELECT * FROM bsp_scripts WHERE name = ?');
        
$query->execute(array('test'));
        
$results = $query->fetchAll();
        foreach(
$results as $row){
            
$path = $row['path'];
        }
        echo 
$path;

 habe ich eine falsche syntax oder irgendwas anderes falsch gemacht?

Original von TheUndeadable

Ich durfte schonmal Quellcode mit japanischen Variablen überprüfen...

Ein übernommenes Projekt verpackte alle Funktionalität mal in Funktionen nach dem Namensschema "function001", "function423", "function051_extra", usw.

OT: Warum will man denn heutzutage noch freiwillig selber SQL statements schreiben für trivialen kram. Versteh ich einfach net :-( Und dann auch noch PDO was einem nun wirklich kaum Arbeit abnimmt. Und weher einer sagt jetzt "performance" -.-

performance! *scnr*

:D

Weil die vielen ORMs, die so rumgeistern bei leicht komplexeren anfragen sofort auseinanderbrechen .. und dann muss man eh wieder direkt sql schreiben. Also kann man es gleich selbst machen und in eine eigene Abstrakionsschicht packen. Ist dann auch gleich viel ordentlicher.

Original von Drezil

Weil die vielen ORMs, die so rumgeistern bei leicht komplexeren anfragen sofort auseinanderbrechen

näh!

Original von Drezil

Ist dann auch gleich viel ordentlicher.

näh!

*schüttel*

Original von BlackScorp

Hm.. ich habe mal PDO ausprobiert. aber irgendwie stürzt apache ab sobald ich eine query ausführe

PHP:

$conn = new PDO('mysql:host='.Defines::$dataBaseServer.';dbname='.Defines::$dataBase.'', Defines::$userName, Defines::$userPassword);
        
$query = $conn->prepare('SELECT * FROM bsp_scripts WHERE name = ?');
        
$query->execute(array('test'));
        
$results = $query->fetchAll();
        foreach(
$results as $row){
            
$path = $row['path'];
        }
        echo 
$path;

 habe ich eine falsche syntax oder irgendwas anderes falsch gemacht?

zurück zum thema:D

Original von BlackScorp

irgendwie stürzt apache ab

Könntest du die Fehlermeldung bitte etwas ungenauer formulieren? :P

Apache logfile angeschaut?

PDO extension installiert?

Willst du nicht lieber etwas anderes als PDO verwenden? Mh? Ja? Braves BlackScorp?!

Original von buhrmi

Apache logfile angeschaut?

[Tue Jun 30 12:28:25 2009] [warn] pid file C:/xampp/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run?

Original von buhrmi

PDO extension installiert?

Original von buhrmi

Willst du nicht lieber etwas anderes als PDO verwenden? Mh? Ja? Braves BlackScorp?!

Hm.. why not.. ich denke ich werde mein eigenen "DB Handler" verwenden

Ich verwende auch einen eigenen DB-Layer.
Ich habe schon einige ORMs getestet.
Aber die anfängliche Euphorie verflog immer schnell wieder.

Für triviale Sachen sind die Dinger echt super, aber sobald es komplex wird... na ja.
Die Performance ist lausig und eine Hilfe ist es dann auch nicht mehr - es ist nur anders.

Als Beispiel mal Propel:

$c = new Criteria(AuthorPeer::DATABASE_NAME);
$c->addJoin(AuthorPeer::ID, BookPeer::AUTHOR_ID, Criteria::INNER_JOIN);
$c->addJoin(BookPeer::PUBLISHER_ID, PublisherPeer::ID, Criteria::INNER_JOIN);
$c->add(PublisherPeer::NAME, 'Some Name');
$authors = AuthorPeer::doSelect($c);

Und equivalent dazu SQL:

SELECT * 
FROM author 
INNER JOIN book ON book.author_id = author.id 
INNER JOIN publisher ON publisher.id = book.publisher_id
WHERE publisher.name = 'Some Name'

Diese proprietäre Syntax von Propel finde ich kein Stück leichter oder lesbarer als pures SQL.

Mein Layer ist mit der Zeit gewachsen und erfüllt alle meine Anforderungen.
Ich verwende das Singleton-Pattern und erweitere einfach mysqli um eigene Methoden.

class database extends mysqli {
}

Meine Models holen sich dann das Datenbankobjekt.

class user {
private $db = NULL;
public function __construct() {
$this->db = database::singleton();
}
}

Propel ist auch wirklich ein ekliges anti-Beispiel @BlackScorp: keine ahnung. gibts denn keine Fehlermeldung

Muss man bei Propel so nutzen? Bei Hibernate ist man freigestellt, und keiner würde wohl auf die Idee kommen, dein genanntes Query in so einen Irrsinn zu verpacken. Es sei denn natürlich, es ist nicht so statisch.. das ist doch der Cloou an der ganze Sache. (Wer dynamisches SQL generiert hat (mit allen Möglichkeiten des SELECT-SQL-Standards), der weiß wovon ich rede).

Diese proprietäre Syntax von Propel finde ich kein Stück leichter oder lesbarer als pures SQL.

Was Criterias angeht: Entweder sind die Standard oder gängige Anwendung.

Mein Layer ist mit der Zeit gewachsen und erfüllt alle meine Anforderungen.
Ich verwende das Singleton-Pattern und erweitere einfach mysqli um eigene Methoden.

Singleton und DB beißen sich ab dem Moment, wo man zwei Datenbankverbindungen benötigt. Beispiel? Anwendung (inkl. Session) und eine andere Datenbank, wie etwa ein Forum (kann bei einem Browserspiel für die Synchronisation vorkommen).

Und soll wirklich der Layer dafür sorgen, das er selber nur einmal existieren darf? Frage der Sichtweise.

Um euch mal ein Beispiel zu geben was ein guter ORM leistet und nicht auf Propel-Kacke herumzureiten um generell alle ORMs schlecht zu reden...:

Z.B. dynamic finders in Datamapper

all_zoos = Zoo.all     # all_zoos ist jetzt ein enumarable aller Zoos
open_zoos = all_zoos.all(open: true) # open_zoos ist ein enumarable aller Zoos mit open=true
big_open_zoos = open_zoos.all(animal_count: 1000) # usw..

So etwas habe ich mal in einer PHP ORM als scopes umgesetzt

PHP:

AbstractRecord::defineScope('visible', array('hidden' => false));
AbstractRecord::defineScope('logged_in', array('last_login <', time()-600));
AbstractRecord::defineScope('voted', array('votes >', 5);

$users = User::find()->visible()->logged_in()->voted(10);

Soetwas eignet sich z.b. besonders gut für komplizierte Suchfrontends:

PHP:

$search = Article::find(array('order' => 'release_date DESC', 'include' => 'author'))
            ->topic_in($topics);
if ($_GET['unread_only']) $search = $search->read(false);
// usw    

 Und es gibt Plugins, automatische Versionierung, automatische Lokalisierung, automatische counter caches, soft-delete, validierung, ............................ *buhrmi gerät ins Schwärmen*

> guter ORM

http://www.hookedonlinq.com/LINQtoSQL5MinuteOverview.ashx

Vollständig durch eine Toolchain unterstützt...

linq ist doch nur ne query sprache und kein orm

Wenn C#, dann castle activerecord oder etwas ähnliches.

ich glaube langsam weichen wir hier vom thema ab oder ich verstehe immer weniger und weniger und das ganze sieht verwirrender und verwirrender aus:D

> linq ist doch nur ne query sprache und kein orm

Linq2sql ist ein ORM...

Aber du hast Recht, ist off-topic, aber ich stimme dir zu, Propel mit seinem Pseudo-SQL ist unsäglich.

wie ist denn das eigentlich mit unterschiedlichen spielewelten? wie kann man es realisieren dass man einen master account hat, sich auf der hauptpage damit einloggt und dann sich auf einer spielwelt aktiviert. man könnte es zwar so machen dass man sich extra für jede spielwelt extra registrieren muss, jedoch dann auch für jede spiel welt einen seperaten admin interface zur account verwaltung erstellen muss. wie habt ihr euren admin interface erstellt? habt ihr für jede spielwelt(server) einen extra admin control pannel oder habt ihr einen acp und der kann dann alle user account von mehreren datenbank holen? ich habe mir das so vorgestellt dass ich useraccount mit login,email etc informationen in einer datenbank abspeichere und die eigentlichen spiele daten wie stadt coordinationen, ingame mails in seperaten datenbanken ablege. also ich weis zur zeit nicht wie ich sowas realisieren könnte. also wie macht ihr das?

MFG

@Masteraccount

Es gibt verschiedene Realisierungsmöglichkeiten; von einer gemeinsamen Applikation (also gemeinsame Session) bis hin zu einem zentralen Loginsystem a la OpenId/OAuth. Letzteres muss man ja nicht nutzen; es reicht völlig, wenn man die entsprechenden notwendigen Schritte realisiert.

Beispiel: Du hast zwei Welten (welt1.domain.tld und welt2.domain.tld) sowie einen Hauptbereich für den Login, sagen wir mal login.domain.tld. Pro Subdomain gibt es eine eigene Session.

1. Benutzer ruft welt1.domain.tld auf.
2. Redirect, weil nicht eingeloggt,  auf welt1.domain.tld/login
3. welt1.domain.tld/login leitet auf login.domain.tld/login/for/welt1 weiter
4. Wenn auf login.domain.tld gibt es keine gültige Session,dann weiter bei 4.1, sonst 5
   

1. Sobald der Login gültig war, erstellt login.domain.tld intern(!) einen Request auf welt1.domain.tld (da wo Benutzer hergekommen ist)

Back-Redirect auf welt1.domain.tld/login oder direkt auf einer Userpage (man ist jetzt hier eingeloggt).

Für jede andere Welt entsprechend analog verfahren.

Die Alternative: Jede Welt selbst fragt mit einer zusätzlichen Datenbankverbindung die Master-Datenbank ab.. damit verteilt, dupliziert man sehr schön viel Loginkram auf allen Servern.

Andere Alternative: Per Cron die Datenbanken synchron halten. Man kann nie synchron genug sein.

Original von knalli

Die Alternative: Jede Welt selbst fragt mit einer zusätzlichen Datenbankverbindung die Master-Datenbank ab.. damit verteilt, dupliziert man sehr schön viel Loginkram auf allen Servern.

geht das denn dass ich für das login masterdatenbank benutze und wenn login erfolgreich ist dass ich dann die spiel-server datenbank benutze?also:

1. user ruft login.domain.tld auf , verbindung zu masterdb hergestellt, login abgefragt

2.login erfolgreich leite weiter auf welt1.domain.tld/index.php?sid=session_id() (quasi session id von login.domain an welt1.domain übergerben). verbindung zu master db trennen, verbindung zu welt1db herstellen. daten aus db holen WHERE sid=$_GET['sid'];

oder muss man wirklich gleiche login tabellen sowohl in der masterdb als auch welt1db haben?

Original von BlackScorp

Original von knalli

Die Alternative: Jede Welt selbst fragt mit einer zusätzlichen Datenbankverbindung die Master-Datenbank ab.. damit verteilt, dupliziert man sehr schön viel Loginkram auf allen Servern.

geht das denn dass ich für das login masterdatenbank benutze und wenn login erfolgreich ist dass ich dann die spiel-server datenbank benutze?also:

Du musst unterscheiden: Das ist das Verwenden von 2 Verbindungen in EINEM Kontext, sprich Script. Ich zitiere mich dazu mal selbst.

Mein Layer ist mit der Zeit gewachsen und erfüllt alle meine Anforderungen.
Ich verwende das Singleton-Pattern und erweitere einfach mysqli um eigene Methoden.

Singleton und DB beißen sich ab dem Moment, wo man zwei Datenbankverbindungen benötigt. 

Und das ist ein Redirect, nicht zwei gleichzeitige Verbindungen:

1. user ruft login.domain.tld auf , verbindung zu masterdb hergestellt, login abgefragt

2.login erfolgreich leite weiter auf welt1.domain.tld/index.php?sid=session_id() (quasi session id von login.domain an welt1.domain übergerben). verbindung zu master db trennen, verbindung zu welt1db herstellen. daten aus db holen WHERE sid=$_GET['sid'];

oder muss man wirklich gleiche login tabellen sowohl in der masterdb als auch welt1db haben?

Und eine technische Anmerkungen: Den Redirect im Schritt 2 meine ich zwar, aber als internen Request. Es geht keinen - nicht mal den Benutzer selbst - die Session-Id etwas an. Man kann, muss aber nicht als Token die Session-Id nutzen.