PHP - sind hier "Sicherheitsexperten" an Board?

[DP-Maintenance]

Dieses Thema wurde am "04. Jul 2010, 20:19 Uhr" von "mkinzler" aus dem Forum "Klatsch und Tratsch" in das Forum "Programmieren allgemein" verschoben.

[himitsu]

Nja, irgendwo war auch ein Test zu sehn, wo InnoDB mindestens doppelt so langsam war.
Außerdem soll InnoDB mehr Speicher belegen. (hab's aber noch nicht getestet)

Mindestens eine Tabelle werde ich vermutlich auch als MEMORY anlegen (mal sehn ob as was ausmacht, ist ja eh nur für 'ne Cache)


Die Volltextsuche werd' ich an ein/zwei Stellen benötigen,
also ich hätte ich mich so oder so je nach Tabelle entschieden.

Also gut, dann mal sehn wie's weitergeht.
Den Kern meines winzigen/kranken CMS hab ich soweit wieder am laufen und alles schön mit Klassen usw.
(Das Einzige, was sich kaum geändert hat, ist meine MySQL-Klasse :stupid: )

[alcaeus]

Moin,

ja, InnoDB ist etwas langsamer als MyISAM. Trotzdem rate ich dir dringendst, InnoDB zu verwenden. Warum?

• MyISAM ist nicht transaktionssicher. Da kannst du dir das DBMS gleich sparen.
• InnoDB ist eine relationale Engine, d.h. du kannst Beziehungen zwischen Tabellen herstellen. D.h. du kannst z.B. das Loeschen eines Benutzers verhindern, solange noch Records vorhanden sind die sich auf diesen Benutzer beziehen - und das ohne durch die Datenbank pfluegen zu muessen.
• InnoDB beherrscht Row-Level-Locking. Bei MyISAM muss immer die gesamte Tabelle gesperrt werden, was im Produktivbetrieb richtig viel Aerger machen kann. InnoDB sperrt auf Zeilenebene, d.h. Schreiboperationen werden parallelisiert.
• InnoDB ist zwar etwas langsamer als MyISAM, skaliert aber signifikant besser. Die Verwendung von RAW-Files fuer die Speicherung der Datenbank (d.h. das DBMS geht am Betriebssystem vorbei und schreibt im RAW-Modus auf die Festplatte. Das ist um einen sehr grossen Faktor schneller - mangels Testsystem kann ich dir da grad keine konkreten Zahlen liefern.

Kurzum: wenn du mit Datenbanken arbeiten willst, nimm InnoDB. Wenn du deine Daten irgendwo parken willst um dich in ein paar Jahren darueber zu aergern dass die DB mehr Loecher in den Relationen hat als die Schweiz im Kaese dann verwende InnoDB. Vertrau mir, InnoDB sollte deine Wahl sein.

Greetz
alcaeus

[himitsu]

Also kann ich es mir sparen verschiedene Engines zu verwenden?
Brauche ja nicht überall diese schönen Sachen und hätte InnoDB jetzt nur da verwendet, wo ich dieses benötigt hätte.


Ich versuch ja grade diese ForeignKeys verwenden zu wollte ... wenn es denn mal ginge.
(kämpfe grade mit diesem blöden "Can't create table 'test.#sql-ce0_ba' (errno: 150)" und noch keiner der Tipps half. )

[alcaeus]

Fuehr nach dem create table mal ein "show innodb status" aus. Da steht dann unter "LATEST FOREIGN KEY ERROR" unter anderem folgendes:

Zitat:

Cannot find an index in the referenced table where the
referenced columns appear as the first columns, or column types
in the table and the referenced table do not match for constraint.

Und ja, verwende InnoDB. Fuer deine Cache-Tabelle kannst MEMORY verwenden, aber beachte dass

1. Keine TEXT/BLOB-Felder moeglich sind und
2. Die Daten bei einem Neustart des MySQL-Servers geloescht werden.

Greetz
alcaeus

PS: obiges Ergebnis ergibt eine Google-Suche nach wenigen Momenten. Nur so als Hinweis.

[himitsu]

Zitat:

Zitat von alcaeus (Beitrag 1033676)

aber beachte dass

1. Keine TEXT/BLOB-Felder moeglich sind und
2. Die Daten bei einem Neustart des MySQL-Servers geloescht werden.

hatte ich schon gelesen :)

Zitat:

Zitat von alcaeus (Beitrag 1033676)

PS: obiges Ergebnis ergibt eine Google-Suche nach wenigen Momenten. Nur so als Hinweis.

Da bin ich schon unterwegs und ja, es liefert massenhaft Ergebnisse,
aber irgendwas stimmt wohl einfach nicht ... weiß nur noch nicht was :cry:

SQL-Code:

CREATE TABLE IF NOT EXISTS `hCMS_Config_Group` (
  `Name` VARCHAR(31) UNIQUE KEY, 
  `Description` VARCHAR(31)
) ENGINE=InnoDB CHARACTER SET utf8 COLLATE utf8_unicode_ci
result: OK

CREATE TABLE IF NOT EXISTS `hCMS_Config` (
  `Name` VARCHAR(63) UNIQUE KEY, 
  `Value` VARCHAR(127), 
  `Type` ENUM ('String', 'Integer', 'Boolean', 'Serialize') DEFAULT 'String', 
  `Description` VARCHAR(31), `Group` VARCHAR(31)
) ENGINE=InnoDB CHARACTER SET utf8 COLLATE utf8_unicode_ci
result: OK

ALTER TABLE `hCMS_Config` ADD INDEX (`Group`)
result: OK

ALTER TABLE `hCMS_Config` ADD FOREIGN KEY (`Group`) 
REFERENCES `Config_Group` (`Name`) ON DELETE NO ACTION ON UPDATE NO ACTION
result (1005): Can't create table 'test.#sql-ce0_ba' (errno: 150)

das sollte doch eigentlich stimmen? :|

"show innodb status" meint dann auch noch irgendwas von

Zitat:

Cannot resolve table name close to:
(`Name`) ON DELETE NO ACTION ON UPDATE NO ACTION

[fkerber]

Hi!

Das Problem steht doch da?!
Er kann `Config_Group` nicht finden, da die Tabelle `hCMS_Config_Group` heißt.


Grüße, Frederic

[alcaeus]

:shock:


:shock:




:shock:










:shock:



Aehm....ja. Bitte, bitte, bitte, mach dich schlau was DB-Design betrifft. Also:
Die Tabelle hCMS_Config_Group hat als Unique-Key einen Varchar von 31 Zeichen Laenge. Da MySQL bei UTF-8 3 Bytes pro Zeichen reserviert hast du dir da grad einen 93 Byte grossen Index gebastelt. Dumme Idee.
hCMS_Config verwendet einen 63 Zeichen langen String, d.h. einen 189 Byte grossen Index. Noch viel duemmer.
Fuer sowas verwendet man numerische Primary-Keys.

Naechster Punkt: hCMS_Config hat einen Index namens `Group`, dieser beinhaltet aber keine Spalten - er bringt also gar nichts.
Du versuchst nun einen Foreign-Key auf diesen Index zu legen welcher auf die hCMS_Config_Group zeigt. Das kann nicht gut gehn.

Greetz
alcaeus

PS: gib es einen Grund warum du deinen Strings so interessante Laengen wie z.B. 31 Zeichen, 63 Zeichen, 127 Zeichen, etc.?

[himitsu]

es raucht ... es raucht ... ruft die Feuerwehr :firejump:

• Viele Felder könnte ich als Binary oder Ansi deklarieren.
  
  Wie ist das mit der den Tabellen und der Datenbankverbindung?
  - Kann ich diese auf UTF-8 eingestellt lassen und wird dann automatisch umgewandelt?
  - oder soll ich alles z.B. auf Ansi umwandeln, nut die größen sprachabhänhingen Textfelder als UTF-8 deklarieren und dann auf PHP-Ebene die Kodierung umwandeln, bzw. kann man nur diese Felder als UTF-8 übertragen lassen.
  .
• Es wird sich vermutlich nicht um rießige Datenmengen handeln.
  Und wenn ich jetzt für alles wirklich nur Integer als Indize und für die ForeignKeys verwende, dann müßte ich an vielen Stellen zusätzliche ID-Name-Umwandlungen einbauen, welche jetzt nicht nötig sind.
  Oder ich muß die Datenbankanfragen so ändern, daß dann auch der Name aus einer anderen Tabelle zur ID in der ausgelesenen Tabelle mit ausgelesen wird (ich weiß, daß es geht ... weiß nur noch nicht wie)
  
  Ist denn wirklich soooooooooooooo schlimm, wenn man nicht alles auf Integer-Verbindungen runteroptimiert und stattdessen Namentliche verwendet?
  Immerhin handelt es sich auch nicht um große Datenmengen, welche auch extrem schnell verwaltet werden müssen ... es soll halt nur einfach sein.
  (OK, abgesehn von dem UTF-8-Problemchen)

Nja, immerhin hab ich nun alles auf Klassen umgestellt, dank der Vererbung und den Autoloadern konnte vieles vereinfacht und automatisiert werden.
(Der Installer suchst sich jetzt z.B. alles selber zusammen, fragt die Klassen nach ihren Datenbank anbindungen und macht dann alles von alleine ... selbst nach erweiterungen muß ich den zukünftig wohl nicht mehr ändern müssen :thumb: , wenn ich dann mal ein ordentliches passendes DB-Design zusammen hab)

[himitsu]

*verwirrung*

Zitat:

Tipp: Um mit UTF-8 Speicher zu sparen, verwenden Sie VARCHAR statt CHAR. Andernfalls muss MySQL 3 Byte pro Zeichen in einer CHAR CHARACTER SET utf8-Spalte reservieren, da dies die maximale Länge ist. So muss MySQL etwa 30 Byte für eine CHAR(10) CHARACTER SET utf8-Spalte vorsehen.

> http://dev.mysql.com/doc/refman/5.1/...t-unicode.html / http://dev.mysql.com/doc/refman/5.1/...code-utf8.html

heißt das nun, daß bei VARCHAR doch nicht 3 Byte für UTF-8 gespeichert werden? :?

Zitat:

utf8mb4, a UTF-8 encoding of the Unicode character set using one to four bytes per character

Wobei das ab MySQL 5.5 doch dann 4 Byte sein müßten. :shock: