Beiträge von SinnlosS

  • Groß-/ Kleinschreibung in der DB

    Naja, da fehlt auch noch der mysql_query() ;)

    PHP
    $sql = "SELECT * FROM enn_usr WHERE firstname='Marian' AND surname='merek'"; 
$res = mysql_query($sql) or die("Fehler mit Query:<br>$sql<br>".mysql_error());
while ($row = mysql_fetch_array($res)) { 
  $usr['firstname'] = $row['firstname'];
  $usr['surname'] = $row['surname']; 
}

  • Groß-/ Kleinschreibung in der DB

    Dann kommt, wie vermutet, die Anfrage nicht mehr korrekt bei der DB an. Damit ist es zumindest schonmal eingegrenzt.
    Schreib doch mal in deiner PHP-Datei folgendes:

    PHP
    // Das hier:
$sql = "SELECT * FROM enn_usr WHERE firstname='".$firstname."' AND surname='".$surname."'";
// ändern in:
$sql = "SELECT * FROM enn_usr WHERE firstname='Marian' AND surname='merek'";


    Funktioniert es dann? Ansonsten kannst du auch nochmal versuchen die Zeichensatz-Formatierung deiner php-Dateien zu ändern.

  • Was ist besser

    Zitat von Pion


    Ich für meinen Teil leite zb alle Anfagen auf die Index weiter



    Dito, mache ich auch so.
    Die Generierung der Daten und der Darstellung läuft dann in der Regel nur noch objektintern.
    Eine klassische index.php sieht dann bei mir so aus:

    PHP
    <?php
require_once "./core/classes/Application.class.php";
$app = new Application();
$app->run();
?>

    Wenn du mit mehreren Dateien arbeitest solltest du dir auf jedenfall eine allgemeine common.php (oder config.php oder wie auch immer) anlegen, in der die Standard-Settings vorgenommen werden, wie session_start, DB-Verbindung herstellen, error_reporting/error_handler definieren, classloader registrieren etc.
    Diese Datei kann dann überall includet werden und du brauchst Änderungen an settings nur noch in einer Datei vornehmen.

  • Groß-/ Kleinschreibung in der DB

    Zitat von Dodo

    Und was soll an ihr unsauber und inperformant sein?

    Zitat von Pion

    Ich denke mal er meint damit das du viel mit PHP rumfrickeln musst obwohl es eigentlich gar nicht nötig bzw die Aufgabe hier ist (von PHP)

    Genau das. Es macht in diesem Fall keinen Sinn Daten vor dem Schreiben in die DB umzuwandeln und beim Auslesen dann jedesmal wieder zurück. Das ist einfach ein Pfuschlösung, die das Problem lediglich etwas aufschiebt. Wenn als nächstes irgendeine Volltextsuche aus ganzen Textabschnitten kommt funktioniert deine Lösung schon nicht mehr, da du dort schon nicht mehr weißt welche Wörter wieder groß geschrieben werden müssen und welche nicht.

    @ naggison: Wenn du beide Felder auf utf8_general_ci stehen hast und es trotzdem nicht klappt kann der Fehler nicht bei der DB liegen, dann kommt der Query nicht korrekt an. utf8_general_ci ist definitiv case-insensitive, dabei spielt es auch keine Rolle ob Datenbank und Datenbankverbindung über utf8_bin läuft.
    Änder mal folgendes in deinem Script und schau mal was dann kommt:

    PHP
    $result = mysql_query("SELECT * FROM enn_usr WHERE firstname='".$firstname."' AND surname='".$surname."'");


// änder in:
$sql = "SELECT * FROM enn_usr WHERE firstname='".$firstname."' AND surname='".$surname."'";
echo $sql;
mysql_query($sql) or die("<br/>".mysql_error());

    Probiert hast du es mit Max Mustermann? Oder evtl. nur mit anderen Namen in denen Umlaute o.ä. vorkommen? Dann könnte es auch noch am Format der php-Datei liegen.

  • Parse Error =(

    zu 1: Du schließt nur die Klammer von empty(), aber nicht die vom if(). Du mußt alle Klammern schließen vor den geschweiften Klammern.
    zu 2: Klar kannst du mehrere GET-Parameter übergeben. Den ersten hängst du mit ? an die URL, alle weiteren dann mit &

  • Passwörter sicher abspeichern

    Ich habe mich mit den verschiedenen Verschlüsselungsverfahren noch nicht so sehr beschäftigt, muss ich zugeben.
    Meines Wissens ist MD5 nicht entschlüsselbar, es gibt lediglich die sogenannten Rainbow-Tables zum Abgleich.
    Daher ist ein reines $pass = md5($pass); natürlich längst nicht mehr ausreichend.
    Aber unter der Annahme, dass md5 nicht entschlüsselbar ist, sondern eben lediglich auf rainbow-tables beim Knacken zurückgegriffen wird, was ist dann an folgender Verschlüsselung unsicher:

    PHP
    $salt = substr(md5(uniqid('',true)),0,23);
            $pw  = md5($pw.$salt.MD5_SALT).$salt;


    MD5_SALT ist eine Konstante die man in einer config-Datei ablegt.
    $salt ist ein md5-Hash aus uniqid('',true) der zum einen vor dem hashen, gemeinsam mit dem konstanten MD5_SALT, an das eigentlich Passwort gehängt wird, und danach nochmal an den Hashwert um diesen Salt beim PW-Check zur Verfügung zu haben. Da dürften doch eigentlich keine Rainbow-Tables mehr greifen?

    Das RSA-Verfahren werde ich mir aber bei Gelegenheit mal anschauen, das sichere Verschlüsseln mit der Option einer Entschlüsselung könnte ich grad gut brauchen, für einen online-Passwortmanager den ich gerade nebenbei entwickle um überall immer Zugriff auf alle meine Passwörter für diverse Seiten, eMails etc. zu haben. Die möchte ich ungern im Klartext in meiner DB ablegen ;)

  • Wie man Geschwindigkeit aus PHP herausholt.

    Mal ein paar kleine Ergänzungen noch, die unabhängig vom Softwaredesign des PHP-Codes sind:

    Mysql - Datums-/Zeitspeicherung
    Zur Speicherung von Datums- oder Zeitwerten die vorgesehenen Feldtypen nehmen (Date, Datetime, Timestamp, Time, Year). Also keine INT-Felder mit unix-timestamps füllen, oder noch schlimmer Varchar-Felder verwenden.
    Mit den vorgesehenen Feldern kann Mysql hervorragend rechnen, Formatierungen und Umformungen vornehmen. Das ist um einiges schneller als die erforderlichen Berechnungen und/oder Umformungen nach dem Auslesen mit PHP vorzunehmen.
    Ich empfehle da jedem sich mit den Datums- und Zeitfunktionen von Mysql vertraut zu machen.

    switch-case-/if-elseif-if-Optimierung
    Sowohl bei switch-Anweisungen, als auch bei if-elseif-if-Konstrukten sollten die Bedingungen die am häufigsten eintreten oben stehen. Sobald dieser Falls auftritt verlässt PHP die Anweisung und spart sich die restlichen Überprüfungen.

    if-Bedingungen: Reihenfolge optimieren
    Ähnliches gilt für mehrere Bedingungen in einer if-/elseif-Abfrage. Bei &&-Verknüpfungen sollten hier die Prüfungen die am häufigsten Fehlschlagen ganz vorne stehen, da PHP in diesem Fall die restlichen Überprüfungen nicht mehr durchführt (-> Kurzschlussauswertung).
    Für ||-Verknüpfungen gilt das Gegenteil: Die Bedingungen die am häufigsten erfüllt werden sollten vorne stehen.


    Einige Selbstverständlichkeiten, die aber leider trotzdem häufig "falsch" gemacht werden:

    Mysql - LIMIT verwenden
    In SELECT-Abfragen sollte LIMIT verwendet werden, sofern nur eine bestimmte Anzahl Ergebniszeilen benötigt wird.

    Filterfunktionen der Datenbank nutzen
    SELECT-Abfragen sollten so formuliert sein, dass sie nur genau die Daten liefern die man auch benötigt. In PHP sollte optimalerweise keinerlei Filterung mehr nötig sein.

    Kein SELECT * verwenden
    http://www.php-faq.de/q-sql-select.html

    COUNT() statt mysql_num_rows
    Wenn man nur die Anzahl der Ergebniszeilen ohne die Ergebnisse selber benötigt, sollte die SQL-Funktion COUNT() verwendet werden, statt sich den Speicher mit dem kompletten Ergebnis zuzumüllen bei dem man dann nur via PHP die Anzahl der Zeilen ausliest.

  • Tagesablauf / Dienstplan

    Zitat von Pion

    Na ich möchte den Timestamp jedes Users ausgeben als Timestamp oder für sonstige Bearbeitungen, nun sollst du mal Benchmarken ob das mit INT oder mit SQL schneller geht

    Ich würde mal tippen mit INT da MYSQL ja erst umwandeln musst^^

    mfg

    Feld `datum`ist vom Typ datetime.
    Feld unixTimestamp vom Typ int(12).


    Ergebnis:
    0.071622133255005
    0.071276903152466

    SQL braucht nicht wirklich lange zum umrechnen eines datetime-Feldes in einen Unix-Timestamp...
    Ich sehe immer noch keinen Grund auf die vorgesehenen Feldtypen zu verzichten, selbst wenn ich in PHP tatsächlich mal den unix_timestamp benötige (was wohl eher die Ausnahme darstellen dürfte).

  • Tagesablauf / Dienstplan

    Zitat von Pion

    Naja also eine Datumsumwandlung haut nun wirklich nicht um.

    Ich finde es nicht problematisch mit INT zu arbeiten


    Klar, problematisch ist es nicht. Und eine Datumsumwandlung haut auch nicht um. Aber was ist mit ganz ganz vielen? :D
    Habe grad mal getestet, weil mich das tatsächliche Verhältnis auch interessiert.
    Die Umwandlung eines date-Feldes in das gewünschte Format per SQL ist 3x so schnell, wie das Auslesen eines Integer-Feldes mit einem Unix-Timestamp und der anschließenden Umwandlung ins gewünschte Format per PHP.

    Ergebnis:
    0.01239800453186
    0.037822008132935

    `regdatum` hat das Format date.
    `regdatum2` hat das Format int(12).
    Die Daten in beiden sind identisch, nur halt einmal im sql-date-format und einmal als Unix-Timestamp.
    Gefüllt ist die Tabelle mit knapp 2700 Datensätzen.

    Zitat von Pion


    :!: Trotzdem sollte man sich DATETIME angewöhnen :!:


    Danke, das wollte ich doch nur hören :D
    ;)

  • Datum aus Text umwandeln.

    Zitat von Thonixx

    Du Kumpel, mir is was nicht klar:
    Was ist jetzt eigentlich noch dein Problem??

    Ich rat dir dazu:
    Mach ein Feld mit dem Typ INTEGER und mach einfach den Timestamp da rein.
    Das macht kaum Probleme und kann überall verwendet werden.

    Nenne mir mal bitte einen Vorteil den es hat ein Datum in der Datenbank in einem Integer-Feld zu speichern, statt die vorgesehenen Feldtypen wie date/datetime/time/timestamp zu nehmen.

    Ich nenne hier schonmal die Vorteile der vorgesehenen Datentypen:
    1. Es können die SQL-eigenen Datumsfunktionen verwendet werden um direkt beim Auslesen die Daten in eine passende Form zu bringen/zu rechnen oder sonstwas. Das ist performanter als einen Unix-Timestamp auszulesen und die Umwandlungen/Berechnungen von PHP vornehmen zu lassen, da SQL klar schneller als PHP ist. Nur weil man vielleicht mit PHP schon weiß wie man das macht und die Datumsfunktionen von SQL eventuell nicht kennt, heißt das noch nicht, dass es sinnvoller ist den Unix-Timestamp zu speichern.
    2. Bessere Lesbarkeit der Daten in der DB.

  • Wie man Geschwindigkeit aus PHP herausholt.

    Zitat von Dodo


    01. "Hallo ".$world; ist schneller als "Hello $world";. Das kommt daher, weil PHP beim parsen eines Strings viele Zeichen überprüfen muss. Durch das beenden des Strings vor dem Anketten einer Variable lässt PHP in einen dementsprechend schnelleren Modus umspringen.


    Ändert sich gelegentlich mit den PHP-Versionen. Unter 5.3.0 und aktueller Version 5.3.3 folgender Benchmark:

    Ergebnis:
    "Hallo {$var} - "
    0.51526999473572
    "Hallo $var - "
    0.51192283630371
    "Hallo ".$var." - "
    1.0051839351654
    'Hallo '.$var.' - '
    1.0279681682587

    Hat mich auch ziemlich erstaunt. Persönlich bevorzuge ich allerdings die Schreibweise "Hallo ".$var." - "
    Zum einen da durch das Konkatenieren eine bessere Lesbarkeit gegeben ist. Zum anderen brauchen bei SQL-Statements die einfachen Hochkommata ' nicht escaped zu werden.

    Zitat von Dodo


    02. ' ist schneller als ". Dies hat einen ähnlichen Grund viel der vorherige Punkt. Bei " müssen einfach viel mehr steuerzeichen überprüft werden, als bei ', wo PHP mehr oder minder einfach drüberfährt.


    Naja, nach der Logik dürfte es aber keinen Unterschied zwischen Konkatenierung und direkter Einbindung geben, bei doppelten Hochkommata ". Entweder muss der String nach Variablen geparst werden, oder nicht.

    Zitat von Dodo


    03. file_get_contents() und file_put_contents() ist schneller, als andere Methoden, um Dateien zu lesen. Die kommt ganz klar daher, dass PHP intern einfach keine Arrays oder ähnliches konstruieren muss.


    Das glaube ich dir einfach mal, habe selber keine Benchmarks dazu gemacht. Klingt aber einleuchtend. Allerdings ist es natürlich gelegentlich auch nötig eine Datei zeilenweise als Array einzulesen. Kommt bei mir häufiger vor.
    Wenn man nur die Funktionalität von file_get_contents() benötigt hast du wie gesagt sicherlich recht.

    Zitat von Dodo

    04. strpos() ist schneller als preg_match() - preg_match() ist schneller als ereg() - Auch die entsprechenden Replace-Funktionen. Das sollte auch jedem klar sein sein, warum. Deshalb immer vereinfachen versuchen.


    Signed.
    Mal davon abgesehen, das ereg() sowieso bald bei PHP rausfliegt und nicht mehr verwendet werden sollte.

    Zitat von Dodo

    05. Bei zu speichernden Daten viel beim Eintragen rechnen. Auslesen kommt öfter vor. Wenn ihr etwa in Datenbanken, Dateien, o.Ä. eintragt, rechnet eher beim Eintragen. Wenn der Eintrag zehn mal ausgelesen wird, erspart ihr euch auch zehn Rechenzyklen.


    Signed.
    Eine Selbstverständlichkeit in meinen Augen. Es werden nur die Daten gespeichert die benötigt werden, und nicht alle möglichen anderen Daten die zusammen erst die Daten ergeben die ich benötige.

    Zitat von Dodo

    06. Wenn möglich, den Output zusammenfassen und auf einmal ausgeben. Die kommt daher, weil echo & Co. mit Datenverkehr verbunden wird. Das erklärt auch den häufigen header()-Fehler. Ein Template-System kann da viel helfen.


    Signed.
    Und "wenn möglich" heißt hier nahezu "immer" (mir fällt grad kein Beispiel ein wo es nicht möglich wäre).
    Ich persönlich nutze jetzt seit einem Weilchen Smarty, sowas hier scheint mir aber auch gar nicht mal so verkehrt:
    http://mylittlehomepage.net/de/sonstiges/u…emplate-engines

    Zitat von Dodo

    07. PHP-Tags schließen, wenn ein langer Text ausgegeben wird. Bevor man mit echo einen langen Text, wie zum Beispiel den Grundaufbau der Seite ausgibt, sollte man eher mit ?> den PHP-Code beenden und auf "Inline-PHP" zugreifen.


    Sowieso, da ich eh für eine strikte Trennung von Code und Ausgabe bin.

    Zitat von Dodo

    08. Output-Buffering und GZip-Kompression verwenden (falls möglich) ob_start() ist eine der nützlichsten funktionen in diesem Bereich. Hier wird jeglicher Output zwischengespeichert und kann anschließend, ähnlich einem Template-System verabreitet werden. Auch GZip-komprimierte Datenübertragungen können viel Geschwindigkeit bringen.


    Mag stimmen, OB sollte aber überflüssig sein, wenn man Code und Ausgabe sauber nach dem EVA-Prinzip trennt.

    Zitat von Dodo

    09. OOP vermeiden. OOP ist eine grandiose Erfindung. Aber nicht für PHP. PHP ist und bleibt eine interpretierte Sprache. Und jede Klasse muss zuerst geparst werden. Außerdem dauert der Zugriff auf Elemente einer Klasse vier mal länger, als auch normale Variablen..


    Naja...
    Natürlich hast du rein auf die Geschwindigkeit bezogen recht. Aber so ein Rat passt hier trotzdem nicht im geringsten rein, weil es bei OOP um ganz andere Dinge geht, als um die Geschwindigkeit. Ich weiß ja nicht was du für PHP-Projekte realisierst, aber wenn du in einem Team ein voll dynamisches, modular erweiterbares, wiederverwendbares System entwickelst, möchte ich mal sehen wie du das mit prozeduralem Code managest. ;)
    Mal ganz abgesehen von der jederzeitigen Wiederverwendbarkeit gut geschriebener Klassen, deren Abstraktionsebene eine anpassungsfreie Einbindung in nahezu jedes Projekt ermöglicht.
    Kurz, die Frage ob OOP oder prozedurale Programmierung wird durch die Komplexität des Pojektes bestimmt, nicht nach Geschwindigkeitsvorteilen.
    Mal abgesehen davon, dass das Klassenmodell in PHP5 wirklich schon gut ist.
    http://professionelle-softwareentwicklung-mit-php5.de/

    Zitat von Dodo

    10. Beim komplexen Algorithmen Schleifendurchgänge zusammenfassen. Falls ihr schon eine etwas komplexere Funktion mit vielen Schleifen geschrieben habt, werdet ihr die Gecshwindigkeit-Lecks von PHP sicher auch schon gesehen haben. Hier hilft es oft Schleifendurchgänge zusammenzufassen und Ausnahmekriterien (wie ersten und letztes Element) explizit zu behandeln. So fällt die überprüfung weg.


    Schleifendurchgänge weitestgehend möglich zusammenfassen ist klar, Selbstverständlichkeit. Aber irgendwie verstehe ich gar nicht was du meint wie man es nicht machen sollte :D

    Zitat von Dodo

    11. Auch mal Heuristiken verwenden. Ein Algorithmus muss nicht immer perfekte Ergebnisse liefern. Gute reichen oft auch. Durch einen einfachen Denkanstoß, kann eine Heuristik große Geschwindigkeitsscüber bringen.


    Das mag wohl sein. :)

    Zitat von Dodo

    12. Viel in den Speicher laden und auf Variablen zurückgreifen, nicht auf Funktionsaufrufe. Wenn ihr die Länge ienes String zehn mal bestimmen müsst, berechnet sie einmal und speichert sie in einer Variable. Zehn mal strlen() benötigt auch eine entsprechend höhere Laufzeit.


    Richtig, es ist sogar fast 3x so schnell:

    Ergebnis:
    0.46727013587952
    0.16079497337341

    Zitat von Dodo

    13. Keine gleichbleibenden Berechnungen in Schleifen lassen, sondern vor die Schleife setzen. Niemals eine Schleife in der Form "for($i = 0; $i < count($array_a); $i++)" implementieren. Bei jedem Schleifendurchgang wird die mittlere Bedingung geprüft. Lieber vor der Schleife in eine Variable schreiben. Das gilt auch für Berechnungen innerhalb der Schleife, die in jedem Durchgang dasselbe Ergebnis liefern.


    Ich verstehe zwar den Unterschied zu 12. nicht, aber es stimmt immer noch.

    Zitat von Dodo

    14. Möglichst simple Variablen-Typen an Unterprogramme übergeben. Arrays und Objekte benötigen viel Rechenzeit. Deshab lieber die gewünschten Werte beim Aufruf auslesen und einzeln übergeben.

    Ergebnis:
    sum_a($array)
    1.5093479156494
    sum_b()
    1.4196450710297
    Der Unterschied ist nicht wirklich signifikant.

    Zitat von Dodo

    15. Objekte und Arrays als Referenzen übergeben. Wenn es wirklich notwendig ist, Arrays und Objekte an Unterprogramme zu übergeben, tut dies per & und macht sie zu Referenzen. PHP kann darauf schneller zugreifen.


    Für Arrays hast du recht. Objekte werden aber sowieso als Referenz übergeben. Wenn man Objekte kopieren will braucht man "clone".

    Zitat von Dodo

    16. Nicht mehr gebrauchte Arrays und Objekte per unset() löschen. Gerade diese großen Variablentypen benötigen viel Speicher. Wer sich schon mal mit dem Speicheraufbau eines Prozessors beschäftigt hat, wird mir zustimmen, dass das freigeben großer Bereiche Leben retten kann.


    Ich habe mich noch nicht mit dem Speicheraufbau eines Prozessors beschäftigt, klingt aber einleuchtend.

    Zitat von Dodo

    17. Möglichst wenig Funtkionsaufrufe, wenn sie nicht unbedingt notwendig sind. Jeder Funktonsaufruf benötigt mehr Zeit, als eine normale Iteration. Deshalb lieber mal Code zwei oder drei mal kopieren, anstatt unnötige Unterprogrammaufrufe zu starten.


    Also wenn ich sowas lese... Natürlich hast du in Bezug auf die Geschwindigkeit recht. Aber was sämtliche andere Belange der Programmierung angeht, als gravierendste Punkte Abstraktion/Wiederverwendbarkeit und Wartbarkeit, ist dieser Tipp noch größerer Unsinn als das Abraten von OOP bei PHP.

    Zitat von Dodo

    18. Datenbanken sollten unbedingt indiziert werden. Das betrifft zwar nicht direkt PHP, aber viele Anwendungsbereiche PHPs. MySQL & Co. bekommen einen enormen GEschwindigkeitsschub durch einen Index.


    Mal abgesehen vom obligatorischen Primärschlüssel ist diese Aussage keinesfalls allgemeingültig. Das Auslesen geht schneller über Indices. Das Schreiben in/Aktualisieren eine/r Tabelle mit Indices dauert aber länger. Daher sollten Tabellen aus denen mehr gelesen wird mit nötigen Indices versehen werden, Tabellen in die mehr geschrieben/in denen mehr aktualisiert wird sollten möglichst frei von Indices gehalten werden.
    Gegebenenfalls kann es Sinn machen eine Tabelle in die normalerweise nur geschrieben wird vor dem Auslesen vieler Datensätze mit einem Index zu versehen und diesen danach wieder zu entfernen, bzw. bei einer Tabelle aus der meist nur gelesen wird Indices zu entfernen wenn viele Datensätze reingeschrieben/aktualisiert werden, und die Indices danach wieder zu setzen.

    Zitat von Dodo

    19. Zend bietet einen PHP Optimizer an, der das Laden und Interpretieren bis zu doppelt so schnell machen kann. Erklärt sich glaub ich von selbst ;D


    Naja, ich tendiere da ja doch eher zu APC.
    http://blog.digitalstruct.com/2007/12/23/php…zend-framework/

    Zitat von Dodo

    20. Webserveroptimierung: Das größte Optimierungspotential steckt jedoch im Server.


    Obligatorisch.

  • Tagesablauf / Dienstplan

    Zitat von Pion

    Also ICH speichere immer den Timestamp in der DB ab und Habe damit keine Problem, woher auch ich speichere ja sogesehen kein Format, lasse es dann je nachdem wie ich es haben möchte bei der Ausgabe formatieren, und 2 Zahlen lassen sich immer noch am schönsten berechnen


    Meinst du den Unix-Timestamp, in einem Integer-Feld dann, oder den SQL-Timestamp in der Form YYYYMMDDHHIISS?
    Falls ersteres: Natürlich kann man das machen,aber es geht auf Kosten der Performance. SQL ist nämlich bekanntermaßen einiges schneller als PHP. Und mit den SQL-Eigenen Datumsfunktionen lassen sich so ziemlich alle Formatierungen/Berechnungen/Umwandlungen schon von SQL erledigen, statt PHP da noch rumrödeln zu lassen. Auch die, in der von mir geposteten Standardantwort bereits angesprochene, Lesbarkeit ist für mich ein ganz klarer Pluspunkt.
    Es hat durchaus seine Gründe, dass SQL eigene Feldtypen für die Speicherung von Datums-/Zeitwerten anbietet.
    Wenn man nur Projekte hat an denen man alleine arbeitet und bei denen die Performance aufgrund niedriger Komplexität/Seitenfrequentierung keine Rolle spielt soll man das natürlich machen wie man möchte und besser mit klarkommt.
    Für professionelle Softwareentwicklung mit hoher Komplexität und für hoch frequentierte Seiten rate ich aber ganz klar zur Nutzung solch sinnvoller Konventionen wie die Verwendung der passenden und vorgesehenen Feld-Typen.
    Die Entwickler von (My)SQL bieten diese Datentypen nicht zum Spaß an, sondern haben sich durchaus etwas dabei gedacht.

    Bitte nicht falsch verstehen, ich will dir nicht in deine Programmiergewohnheiten reinreden oder diese per se schlecht machen. Ich möchte lediglich auf den Nutzen von Konventionen und vorgesehener Standard-Funktionalitäten hinweisen, da ich selbst in der Vergangenheit schon oft genug auf die Nase geflogen bin und mir ein zig-faches an Arbeit aufgehalst habe, durch Nichtbeachtung selbiger.