was spricht im allgemeinen eig. gegen eine innodb engine?
gerade bei so vielen transaktionen, find ich es sinnvoll...wollte schon bei sehr vielen addons (z.b. bonuslosehandel) transaktionssicherheit einbauen, was ja bekanntlich myisam leider nicht unterstützt...auch fremdschlüssel wäre doch was tolles. da beim vms sehr viele transaktionen vonstatten gehen, wäre das doch sinnvoll? über ne kleine diskussion würd ich mich freuen
Hab dazu mal eben ein eigenes Thema gemacht
Ich bin dagegen, da InnoDB durch die Transaktionssicherheit etc. um einiges langsamer ist
Vor allem, weil es relativ viele Abfragen gibt (die in den Addons eh nicht durch Transaktionen gesichert werden, weil die Addons meist ziemlich... ja, wissen wir ja) und MyISAM da schneller ist.
Kurz: Transaktionen wird (fast) kein Addon-Bauer verwenden, und nur fürs Standard-Script meiner Meinung nach nicht nötig
Sicherlich wäre InnoDB für manche Tabellen praktisch und sinnvoll.
Besonders da je nach Einsatz das mit der Performanz auch nicht unbedingt zutrifft (1), andererseits ist es nicht unbedingt notwendig (da ja viele VMS1' mit vielen Usern auch so ohne größere Probleme laufen).
Punkt 2 und 3 muss ich Sebmaster zustimmen, wenn sich jemand mit beschäftigt kann er für sich selber das umstellen, aber der Großteil der Nutzer braucht das nicht bzw. beschäftigt sich eh zu wenig mit dem Thema
Und warum kann man im VBB keine Footnotes machen? (Oder warum weiß ich nichts davon?)
Kill one man, and you are a murderer.
Kill millions of men, and you are a conqueror.
Kill them all, and you are a god. - Jean Rostand, Thoughts of a Biologist (1939)
Gescheite Querys und/oder Subquerys ohne Cross-Tables würden da schon mehr reissen als eine komplette Umstellung auf Inno, passend dazu dann natürlich auch PHP5-Klassen, um nicht jeden fetzen Code 100 mal im Script zu haben
Ich hatte vor ca 8/9 Monaten mal eine Mysql-Query (einfache Bedingungen) welche über 3-4 Tabellen ging und rund 15000 Datensätze liefern sollte, die Query hat bei mir (Netzwerk-server: 2 x 2 GHz, 3 GB Ram) rund 40 Sekunden gedauert.Zitat von tampulin
Nachdem ich die Query komplett neu geschrieben habe (left join) hat die gleiche Query mit den gleichen Datensätzen und der gleichen Anzahl der Datensätze nurnoch rund 0,05 Sekunden gedauert.....Das meinte ich mit gescheite Querys bauen
Der Unterschied war so gewaltig, das ich heute 10 mal prüfe, wie schnell die Query ist....Query ist eben nicht Query
Das PHP OOP-Klassen 20% Performance brauchen halte ich für "aus der Luft gegriffen", genauso das ein gescheiter SQL-Layer bis zu 60% braucht....wo nimmst du solche Weisheiten her? Klammforum?
Ich denke dein vorheriger Post kam so rüber, als würdest du lieber ein paar mehr Anfragen an die DB stellen
*gähn* Also wenn wir uns über sowas streiten, dann könnte wir ja gleich ab PHP 5.3 auf den nativen MySQL-Treiber umstellen...
Abgesehen davon wurde das Objektmodell in PHP 5 um einiges verbessert (gegenüber von PHP 4). Nichtsdestotrotz verlangt es immer noch mehr Power ab, als einfaches reinschreiben des Codes...
Wenn ich eine unbekannte DB mit verschiedenen Kollationen habe, bleibt mir schon fast nichts mehr anderes übrig, den ein Subselect oder LEFT / RIGHT / OUTER / INNER sowie GROUP schlägt da fehl und funktioniert nur, wenn alle Tabellen die gleiche Kollation haben.Ich denke dein vorheriger Post kam so rüber, als würdest du lieber ein paar mehr Anfragen an die DB stellen
Da das aber die wenigsten wissen, werden sie aufgeben und einzelne Querys machen......
Hmm, das Problem mit den Kollationen hatte ich schon beim Adscan-Addon, aber ich hab keine Ahnung, warum mir der andere Kollationen in meine Tables reinstopft, als in die vom Standard-VMS
vll hilft dir ja das weiterHmm, das Problem mit den Kollationen hatte ich schon beim Adscan-Addon, aber ich hab keine Ahnung, warum mir der andere Kollationen in meine Tables reinstopft, als in die vom Standard-VMS
mysql_query('SET NAMES latin1, CHARACTER SET latin1;');
Berechtigungen
Zitieren
