Suchergebnisse

Warum wird nicht statt dessen die Datenbanktabelle normalisiert?

Er versucht doch schon seit dem ersten Beitrag sich mit Händen und Füßen gegen OOP zu wehren. Und so verschwendet er sinnlos Zeit in etwas, was mit Zend_Db, Doctrine, Propel usw. schon längst erledigt wäre (wie die meisten anderen auch).

@achtelpetit: darüber wird aber auch gestritten. Viele sagen solche Buisness-Logik gehört in die Applikation und die Datenbank ist nur ein dummer Datenspeicher. Das ganze natürlich ab einem gewissen Level der Komplexität.

extract($_POST); AUF KEINEN FALL BENUTZEN! Das kann ebenfalls zu Sicherheitsproblemen führen! Außerdem unbedingt meine Hinweise zum Escaping beachten!

Ob's an date.timezone liegt?

Zum Thema Sicherheit: $_SERVER['PHP_SELF'] bzw. PHP_SELF nicht benutzen, da es potenziell gefährlich sein kann. Z.B. durch Verwendung von: http://www.domain.com/foobar.php/%22%3Ciframe%20src=http://www.hackme.com%3E%3C/iframe%3E. kann ein iframe eingeschleust werden. action="" reicht völlig...

Stattdessen die Queries optimieren und anständig cachen.

Unnötige Erzeugung von Objekten ja. Da geht's sicher auch im das Lazy-Loading von Klassen: PHP: Autoloading - Manual

Du hast es erfasst. Man kann prozedural oder objektorientiert arbeiten. OOP bringt nur einige Vorteile, die man mit prozeduraler Programmierung nicht erreichen kann. Dafür ist die Lernkurve hoch und es gibt auch einige Nachteile. Und wo hast du da keinen Sinn von Klassen gefunden? Mir...

Wikipedia: D.h. das Datenmodell ist einfacher, solche Daten lassen sich einfacher speichern und schneller abrufen.

Das erledigt PHP. Hier mit Hilfe von Smarty. Das hat mit HTML erst einmal nicht zu tun.

Wozu musst du diese denn zählen? Wenn du debuggen willst, dann hilft dir da Xdebug. Wenn du Profilen möchtest, dann ebenfalls Xdebug.

Die Anforderungen an einer Webapplikationen können sich mit der Zeit ändern. Das kann Kosten- oder Effizienzgründe haben. Mit meinen Anforderungen hat das rein gar nicht zu tun. Und dass das im konkreten Fall bei Datenbanken der Fall sein kann zeigt der Bedarf an solchen...

Vorteil von meiner Implementation ist eben, dass die Adapter gekapselt sind. D.h. es kann auch Mysqli, PDO_Sqlite oder MeineXmlDatenbank implementiert werden und über das einheitliche Interface genutzt werden. Genau das macht OOP ja aus.

Lieber so: class My_Db_Adapter_Pdo_Mysql { protected $_connection = null; protected $_database = null; protected $_host = null; protected $_port = null; protected $_username = null; protected $_password = null; protected $_charset = null; /** *...

Der Konstruktor kann keinen Wert zurückgeben. $db enthält somit ein Objekt der Klasse „DB“. Es ist auch sinnfrei, denn so könnte man direkt auf dem PDO-Objekt arbeiten.

Sicher kann man mit richtigem Cache die Abfragen optimieren. Die Datenbank bezüglich Mehrsprachigkeit muss sowieso normalisiert werden. Warum man aber für den statischen Inhalt keine Standardtools nutzt erschließt sich mir nicht. Ein $this->translate('Welcome') ist viel bequemer als ein...

Gettext oder der Industriestandard Xliff als Übersetzungsdatei. Das Ganze cachen, damit es schnell bleibt. Zend Framework liefert da: Zend Framework: Documentation: Adapter für Zend_Translate - Zend Framework Manual

Der Garbage Collecter räumt auf; mit __destruct() kann man das testen.

Warum ist der Adapter nicht gleich eine Klasse speziell für PDO_Mysql, damit wir für Mysqli, PDO_Sqlite usw. ein einheitliches Interface haben? class My_Db_Adapter_Pdo_Mysql extends My_Db_Adapter_Pdo_AbstractAdapter { protected $pdo; const KEY_QUOTE = '´'; public function...