AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein PHP - sind hier "Sicherheitsexperten" an Board?
Thema durchsuchen
Ansicht
Themen-Optionen

PHP - sind hier "Sicherheitsexperten" an Board?

Ein Thema von himitsu · begonnen am 29. Jun 2010 · letzter Beitrag vom 9. Aug 2010
Antwort Antwort
Seite 6 von 8   « Erste     456 78      
4. Jul 2010, 20:19
Dieses Thema wurde am "04. Jul 2010, 20:19 Uhr" von "mkinzler" aus dem Forum "Klatsch und Tratsch" in das Forum "Programmieren allgemein" verschoben.
Benutzerbild von himitsu
himitsu
Online

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.031 Beiträge
 
Delphi 12 Athens
 
#52

AW: PHP - sind hier "Sicherheitsexperten" an Board?

  Alt 4. Jul 2010, 20:38
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 )
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
Benutzerbild von alcaeus
alcaeus

Registriert seit: 11. Aug 2003
Ort: München
6.537 Beiträge
 
#53

AW: PHP - sind hier "Sicherheitsexperten" an Board?

  Alt 5. Jul 2010, 22:11
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
Andreas B.
Die Mutter der Dummen ist immer schwanger.
Ein Portal für Informatik-Studenten: www.infler.de
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu
Online

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.031 Beiträge
 
Delphi 12 Athens
 
#54

AW: PHP - sind hier "Sicherheitsexperten" an Board?

  Alt 5. Jul 2010, 22:19
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. )
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
Benutzerbild von alcaeus
alcaeus

Registriert seit: 11. Aug 2003
Ort: München
6.537 Beiträge
 
#55

AW: PHP - sind hier "Sicherheitsexperten" an Board?

  Alt 5. Jul 2010, 22:24
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.
Andreas B.
Die Mutter der Dummen ist immer schwanger.
Ein Portal für Informatik-Studenten: www.infler.de
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu
Online

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.031 Beiträge
 
Delphi 12 Athens
 
#56

AW: PHP - sind hier "Sicherheitsexperten" an Board?

  Alt 5. Jul 2010, 22:33
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

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

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
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu ( 5. Jul 2010 um 22:40 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von fkerber
fkerber
(CodeLib-Manager)

Registriert seit: 9. Jul 2003
Ort: Ensdorf
6.723 Beiträge
 
Delphi XE Professional
 
#57

AW: PHP - sind hier "Sicherheitsexperten" an Board?

  Alt 5. Jul 2010, 22:41
Hi!

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


Grüße, Frederic
Frederic Kerber
  Mit Zitat antworten Zitat
Benutzerbild von alcaeus
alcaeus

Registriert seit: 11. Aug 2003
Ort: München
6.537 Beiträge
 
#58

AW: PHP - sind hier "Sicherheitsexperten" an Board?

  Alt 5. Jul 2010, 22:48























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.?
Andreas B.
Die Mutter der Dummen ist immer schwanger.
Ein Portal für Informatik-Studenten: www.infler.de
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu
Online

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.031 Beiträge
 
Delphi 12 Athens
 
#59

AW: PHP - sind hier "Sicherheitsexperten" an Board?

  Alt 5. Jul 2010, 23:15
es raucht ... es raucht ... ruft die Feuerwehr
  • 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 , wenn ich dann mal ein ordentliches passendes DB-Design zusammen hab)
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu ( 6. Jul 2010 um 15:54 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu
Online

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.031 Beiträge
 
Delphi 12 Athens
 
#60

AW: PHP - sind hier "Sicherheitsexperten" an Board?

  Alt 7. Jul 2010, 10:45
*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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu ( 7. Jul 2010 um 10:47 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 6 von 8   « Erste     456 78      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:08 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz