Neuigkeiten
  • Die modified eCommerce Shopsoftware ist kostenlos, aber nicht umsonst.
    Spenden
  • Damit wir die modified eCommerce Shopsoftware auch zukünftig kostenlos anbieten können:
    Spenden
  • Thema: Verwendung von MySQLi in modified eCommerce Shopsoftware sinnvoll?

    RossiRat

    • Fördermitglied
    • Beiträge: 96
    Die Forensuche ergab zu "MySQLi" nur zwei Treffer die keinen Bezug auf die Shop-Software haben. Daher hier meine Frage:

    Macht es Sinn den modified eCommerce Shopsoftware Core von MySQL nach MySQLi zu portieren? Hat jemand schon Erfahrungen mit den möglichen Vorteilen (Geschwindigkeit, Sicherheit, etc.) und dem anfallenden Arbeitsaufwand gemacht?

    Kann jemand generell etwas zu persönlichen Erfahrungen zum Einsatz von MySQLi bei Shop-Projekten oder ähnlich anspruchsvollen Datenbank Anwendungen berichten?

    MySQLi wird ja von Oracle/MySQL empfohlen und die Anbindung über PHP MySQL als Veraltet hingestellt. Es wäre schön wenn jemand hier aus erster Hand berichten könnte.



    Linkback: https://www.modified-shop.org/forum/index.php?topic=11642.0

    DokuMan

    • modified Team
    • Beiträge: 6.669
    • Geschlecht:
    Hi RossiRat,

    ich habe die kompletten Funktionen testweise mal auf mysqli (prozedural) umgestellt. Wenn du möchtest, kann ich dir die .inc-Dateien zur Verfügung stellen.
    Das Ergebnis ist aber teilweise ernüchternd (man darf keine großartigen Geschwindigkeitszuwächse erwarten).
    Das Problem an der Sache, sind allerdings die Webhoster, die die mysqli-extension (obwohl standardmäßig in PHP5 enthalten) nicht mit anbieten. :(

    RossiRat

    • Fördermitglied
    • Beiträge: 96
    Danke für das Angebot. Die geänderten "inc" Dateien würden mich sehr interessieren. :)

    Geschwindigkeitsschübe habe ich mir nicht wirklich erhofft. Da bringt intelligentes Caching sicherlich mehr als der Wechsel auf MySQLi. Nur da die neue Schnittstelle auf immer mehr PHP Webseiten angepriesen wird und der alte MySQL Connector als veraltet deklariert ist, habe ich halt mal drüber nachgedacht. :coffee:

    DokuMan

    • modified Team
    • Beiträge: 6.669
    • Geschlecht:
    Das ist aber nur zum testen und sollte (noch) nicht produktiv verwendet werden (proof-of-concept).

    peterdd

    • Neu im Forum
    • Beiträge: 31
    Interessant ist sind doch eher technische Möglichkeiten die damit eröffnet werden. Damit wäre es möglich, ein paar Workarounds im Webshop zu beseitigen und somit den Shopquellcode zu verbessern.

    Deshalb wäre eine die Info, "ist genau so gut verwendbar wie die klassische mysql-Schnittstelle" hilfreich.

    peterdd

    • Neu im Forum
    • Beiträge: 31
    Hallo, ich habe mir überlegt, wie man die ganze Sache elegant lösen könnte:

    1.
    In allen configuration.php wird eine neue Konfigurationskonstante eingeführt:
    Code: PHP  [Auswählen]
    define('DB_INTERFACE',''); # moegliche Werte: '' leer lassen fuer altes Arbeitsweise, 'mysql' (klassisch, aber deprecated), TODO: 'mysqli', 'PDO', weitere ..

    2a. Alle xtc_db_* Funktionen, die keine dbinterface-spezifischen Aufrufe haben werden in inc/xtc_db_generic.inc.php gespeichert.

    2b. Alle xtc_db_* Funktionen, die dbinterfacespezifische Aufrufe haben, werden in
    'inc/xtc_db_'.DB_INTERFACE.'inc.php' gespeichert.
    also
    inc/xtc_db_mysql.inc.php für das alte mysql_* Interface
    inc/xtc_db_mysqli.inc.php für das mysqli Interface
    usw.

    3. In allen application_top*.php wird der Wert von DB_INTERFACE dazu genutzt, wie die db-Funktionen geladen und genutzt werden:
    Code: PHP  [Auswählen]
    // Database
    # 20141127 Peter Vorbereitung flexibles dbinterface
    if(DB_INTERFACE !=''){
            require_once(DIR_FS_INC.'xtc_db_generic.inc.php');
            require_once(DIR_FS_INC.'xtc_db_'.DB_INTERFACE.'.inc.php');
    }else{
        # bisherige Einbindung
           require_once(DIR_FS_INC.'xtc_db_connect.inc.php');
            require_once(DIR_FS_INC.'xtc_db_close.inc.php');
            require_once(DIR_FS_INC.'xtc_db_error.inc.php');
            require_once(DIR_FS_INC.'xtc_db_perform.inc.php');
            require_once(DIR_FS_INC.'xtc_db_query.inc.php');
            require_once(DIR_FS_INC.'xtc_db_queryCached.inc.php');
            require_once(DIR_FS_INC.'xtc_db_fetch_array.inc.php');
            require_once(DIR_FS_INC.'xtc_db_num_rows.inc.php');
            require_once(DIR_FS_INC.'xtc_db_data_seek.inc.php');
            require_once(DIR_FS_INC.'xtc_db_insert_id.inc.php');
            require_once(DIR_FS_INC.'xtc_db_free_result.inc.php');
            require_once(DIR_FS_INC.'xtc_db_fetch_fields.inc.php');
            require_once(DIR_FS_INC.'xtc_db_output.inc.php');
            require_once(DIR_FS_INC.'xtc_db_input.inc.php');
            require_once(DIR_FS_INC.'xtc_db_prepare_input.inc.php');
    }
     

    Vorteile:
    • Es kann einfach zwischen mysql, mysqli usw umgeschaltet werden. Weicher Übergang von alt zu neu.
    • Die Wartung der DB-Funktionen wird erheblich vereinfacht.
    • Weitere Datenbankenarten können unabhängig von der Entwicklung des Shopkernes hinzugefügt und gepflegt werden, sofern das Interface xtc_db_* für alle Datenbankarten gleich bleibt.

    Danach kann man die einzelnen Dateien inc/xtc_db_connect.inc.php usw. als deprecated markieren und irgendwann ganz aus dem inc/ entfernen.

    Habe das jetzt bei mir so gemacht, muss aber noch das xtc_db_mysqli.inc.php auf Basis von xtc_db_mysql.inc.php umbauen, dann kann ich Erfahrung und Dateien teilen.

    mr.mc.mauser

    • Fördermitglied
    • Beiträge: 343
    • Geschlecht:
    Deine Idee ist gut.

    NUR:
    es gibt ca. 383 Stellen im Standardshop an denen
    z.b.
    mysql_query('SHOW TABLES FROM `' . DB_DATABASE . '`');
    steht.

    All diese stellen müsste man zunächst nach z.b. xtc_db_query() ändern.
    Wenn das gemacht ist könnte es so wie Du meinst sinn machen.

    web0null

    • Experte
    • Beiträge: 1.998
    Na ja ich weiß ja nicht welche Version du verwendest, aber wenn man das umstellt sollte man sowieso eine aktuelle Version haben, und da kommt "mysql_query" gerade mal in 11 Dateien vor.

    Gruß

    webald

    • modified Team
    • Beiträge: 2.791
    Ich wäre für eine sauberere Trennung von Shop und Datenlogik. Ich wäre dafür alle Abfragen in eigene Klassen auszulagern und nur noch als Funktion aufzurufen. Die Shoplogik arbeitet dann ur noch mit der Datenbankfunktion und übergibt bzw. erhält ein Daten-Array. Neue Abfragen, z. B. wegen zusätzlicher Felder, sind dann viel sauberer zu integrieren.

    Mit der Auslagerung der Datenbankabfragen ist es dann auch relativ einfach auf eine andere DB umzustellen.

    Dann trennt man noch Core und Benutzererweiterung indem man alle zusätzlichen Abfragen in eine eigene Datei auslagert und diese nur mit include in den Core einbindet. Macht Updates erheblich einfacher.

    Aber wie ich bereits an anderer Stelle schrib ist das etwas für eine Software-Architekten und den gibt es hier wohl nicht bzw. fehlt die Zeit.

    hpzeller

    • Experte
    • Beiträge: 4.129
    • Geschlecht:
    Na ja ich weiß ja nicht welche Version du verwendest, aber wenn man das umstellt sollte man sowieso eine aktuelle Version haben, und da kommt "mysql_query" gerade mal in 11 Dateien vor.

    Gruß

    Ausser der Funktion 'mysql_query()' währen da noch 'mysql_num_rows()', 'mysql_fetch_row()', 'mysql_real_escape_string()', 'mysql_error()', 'mysql_field_name()', 'mysql_get_client_info()', 'mysql_affected_rows()', 'mysql_fetch_array()' (Aufzählung nicht vollständig) die alle auch geändert werden müssen.

    Aber egal wie gross der Aufwand ist, die Erweiterung MySQL gilt seit PHP 5.5.0 als veraltet und muss deshalb ersetzt werden, mit was auch immer.

    Gruss
    Hanspeter

    peterdd

    • Neu im Forum
    • Beiträge: 31
    Soo,

    also ich kann schonmal sagen, dass es mit meinem Vorschlag so machbar ist, denn ich habe das jetzt so umgesetzt. Allerdings ist es kein modified-shop, aber ist auch ein xt:c-fork.

    Als Test dient ein lokaler xampp mit php 5.4.7 bei mir.

    Es müssen im Shop alle mysql_* auf die xtc_db_ Art umgestellt werden. Allerdings sollte man schon genau hinschauen, also mit einfachem suchen/ersetzen ist es nicht getan. Manchmal entfällt z.B. ein mysql_error() nach einem mysql_query(), weil die Fehler in xtc_db_query() schon abgearbeitet werden usw.

    Interessanterweise kam nach dem Umschalten auf mysqli über die Einstellung define('DB_INTERFACE','mysqli'); in configure.php dann ein Bug in
    includes/functions/sessions.php zutage. Hier mein Fix:

    Code: PHP  [Auswählen]
    function xtc_session_close() {
            # 20141129 Peter: Es gibt kein session_close() laut php.net
           #if(function_exists('session_close')) {
           #       return session_close();
           #}
           return session_write_close();
            # end 20141129
    }
     

    Und in application_bottom.php(Shop und Adminbereich) ganz am Ende:
    Code: PHP  [Auswählen]
    ...
    xtc_session_close();
    ?>

    Zu Kommentar von webald: Dann kannst du gleich eine andere Shopsoftware nehmen, die das von grundauf so macht. Ich finde es aber angenehmer, wenn ich meine SQL-Queries selber schreiben und optimieren kann und nicht auf ein nochmal drübergestülptes Framework angewiesen bin. Das darf man dann nämlich auch erstmal lernen.

    Ausserdem gibt es schon ein paar xtc-Funktionen die sowas anbieten, aber der Nutzen hält sich in Grenzen. Oft gucke ich, ob sich der Aufruf der Funktion überhaupt lohnt.

    Aber manchmal mache ich Queries mit 5,6,7 JOINS und UNIONS für bestimmte Funktionalitäten, die kann keiner voraussehen. Da würdest du dann da stehn und im php eine Schleife nach der anderen durchwurschteln mit framework/klassen/Funktionsaufrufen, während in Villariba schon längst vor sich hingeidlet wird. ;-)

    mr.mc.mauser

    • Fördermitglied
    • Beiträge: 343
    • Geschlecht:
    Na ja ich weiß ja nicht welche Version du verwendest, aber wenn man das umstellt sollte man sowieso eine aktuelle Version haben, und da kommt "mysql_query" gerade mal in 11 Dateien vor.

    Gruß
    stimmt mysql_query gibt es nur 11 Mal was noch schlimm genug ist.
    daher war
    Zitat
    z.b. mysql_query('SHOW TABLES FROM `' . DB_DATABASE . '`');
    vielleicht bisserl unverständlich, Es sind insgesamt 383 vorkommen von mysql_ in der Aktuellen Shop Version

    Ich finde es gut was rö gerade am aufbauen ist. Voralem sein hinweiss
    Zitat
    Es müssen im Shop alle mysql_* auf die xtc_db_ Art umgestellt werden.
    Versteh eh nicht warum das noch nicht so als Standard ist.

    webald

    • modified Team
    • Beiträge: 2.791
    Ausserdem gibt es schon ein paar xtc-Funktionen die sowas anbieten, aber der Nutzen hält sich in Grenzen. Oft gucke ich, ob sich der Aufruf der Funktion überhaupt lohnt.

    und dann schreibt Du neu, was die Übersichtlichkeit und Wartbarkeit erschwert.

    Aber manchmal mache ich Queries mit 5,6,7 JOINS und UNIONS für bestimmte Funktionalitäten, die kann keiner voraussehen. Da würdest du dann da stehn und im php eine Schleife nach der anderen durchwurschteln mit framework/klassen/Funktionsaufrufen, während in Villariba schon längst vor sich hingeidlet wird. ;-)

    Wo kommt das im Shop vor? Das sind doch eher besonder Statistiken, für die Du das brauchst, aber nicht für den normalen Shopbetrieb. Abgesehen davon könnte eine Aufspaltung in verschiedene Funktionen auch zu einen Geschwindigkeitsvorteil werden, gerade bei sehr umfangreichen Abfragen. Das Stichwort heißt Parallelität, v. a. wenn ich UNION lese.

    Ich sehe die Trennung schon auch für den unbedarfteren Nutzer. Wir lesen hier oft genug "wie lauter der SQL" oder "wo steht die Abfrage". Wenn das gesammelt in einem Bereich steht, erhöht das Wartbarkeit, Übersichtlichkeit und Verständnis.

    In einem anderen Thema habe ich mal so einen Ansatz skizziert: http://www.modified-shop.org/forum/index.php?topic=31590.msg287651#msg287651

    peterdd

    • Neu im Forum
    • Beiträge: 31
    Dateien zum Download in neuen Thread in Installation/Upgrade:

    http://www.modified-shop.org/forum/index.php?topic=31664.0
               
    anything