Fehler bei eigener PHP/MySQL-Funktion

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Fehler bei eigener PHP/MySQL-Funktion

    Guten Abend,

    ich habe ein größeres Projekt geplant, und mir daher meine eigene Query-FUnktionen gebaut, die mir persönlich besser gefällt als das Original. Diese sieht wie folgt aus:

    PHP-Code:
    function insert_mysql($table$column$values)
    {

    $insert mysql_query("INSERT INTO $table ($column) VALUES ($values)");


    Der Aufruf der Funktion sieht demnach so aus:

    PHP-Code:
    insert_mysql('test','name, number''"simbo", 23423'); 
    Der erste Parameter entspricht dem Tabellenname, der zweite Paramter der hinzuzufügenden Spalten und der dritte Parameter den entsprechenden Werten.
    Funktioniert alles soweit so gut. Probleme entstehen nur dann, wenn ich andere Variablentylen als STRING benutze, beispielsweise INTEGER (Spalte "number" soll bspw. als INTEGER gespeichert werden). Diese werden in der DB als String gespeichert, was ich daran erkenne, dass bei var_dump die Werte als STRING angezeigt werden.

    Jetzt hätte ich einige, Fragen, die Hauptfrage jedoch zu Anfang:

    1. Wie kann ich diese Werte korrekt als Integer in der DB speichern?

    Die beiden anderen Fragen:

    2. Die Spalte "number" hat den Variablen-Typ INTEGER - sollte da nicht ein DB/PHP-Fehler kommen, wenn ich Daten im STRING-Format einspeichere? Sonst hätte die Voreinstellung des Variablentypes einer Spalte ja gar keien Daseinsberechtigung?!

    3. Wenn ich aus 2 Datensätze die jeweiligen Werte aus der Spalte "number" addiere ($var1+$var2), dann werden die beiden Werte als Integer behandelt und mathematisch addiert und NICHT als STRING zusammengesetzt (aus 2+5 wird also 7 und nicht 25). Wie ist das zu erklären? Ist das bei PHP immer so?!


    Wär genial wenn ihr mich hier etwas unterstützen könntet!

    Danke!

    Alex

  • #2
    Zitat von Alex87 Beitrag anzeigen
    und mir daher meine eigene Query-FUnktionen gebaut, die mir persönlich besser gefällt als das Original.
    Ich halte sie für großen Murks.

    Die mag dir vielleicht momentan „einfacher“ zu handhaben erscheinen - aber sie verführt sicher auch dazu, sich neben Schreibarbeit auch das wirkliche Nachdenken über Queries und darin vorkommende Spalten und Daten zu „ersparen“. (Kontextgerechte Behandlung der Daten sehe ich da auch keine - nimmst du die beim Aufruf der Funktion vor?)

    Auf Grund der Blödsinnigkeit deines Vorhabens werde ich auf deine Detailfragen also gar nicht näher eingehen (sondern dir nur raten, „lass den Quatsch“), bis auf diese eine:
    Wenn ich aus 2 Datensätze die jeweiligen Werte aus der Spalte "number" addiere ($var1+$var2), dann werden die beiden Werte als Integer behandelt und mathematisch addiert und NICHT als STRING zusammengesetzt (aus 2+5 wird also 7 und nicht 25). Wie ist das zu erklären?
    Damit, dass + der Additionsoperator ist (und das PHP eine automatische Typkonvertierung betreibt) - der Operator zur Stringverkettung ist ein anderer.

    Wenn du noch nicht mal so viel über die Grundlagen von PHP weißt - dann solltest du daran viel eher erst mal arbeiten, bevor du versuchst, eigene Funktionen für den Umgang mit der Datenbank zu entwerfen.
    I don't believe in rebirth. Actually, I never did in my whole lives.

    Kommentar


    • #3
      Ja, ich bin kein PHP-Experte, mach mal wieder was mit JavaScript, dann wieder PHP, da kommt man schnell durcheinander. Daran sollte es aber nicht scheitern, muss eben viel rumprobiert werden.

      Was meinst du mit "Kontextgerechte Behandlung der Daten"? Kontrolle ob richtiger Datentyp beim externen Erhalt der Daten? Das wird vor Aufruf der Funktion gemacht...aber muss noch gemacht werden hehe.

      Hast du für Frage 2 eine Antwort? Würd mich brennend interessieren, was diese Definition der Variablentypen in der DB dann überhaupt für einen Sinn hat.

      Und falls du meine erste Frage beantworten kannst, wär es trotzdem klasse, wenn du das tun könntest. Ich sehe ein, dass diese Art der Query alles andere als gut programmiert ist...ich tu mich damit halt leichter. Aber Man sieht ja, was dann wieder für Probleme entstehen. Wie das EInfügen von Integerdaten mit meiner Funktion gehen würde, wäre dennoch spannend zu wissen...

      Kommentar


      • #4
        was wahsaga meint, man schreibt keine "nackten" Post-Daten direkt in die Datenbank .. das ist eine nette Sicherheitslücke (SQL-Injection) ...

        idR schiebt man die Daten durch mysql_real_escape_string() um eben diese SQL-Injection auszuhebeln ...


        nun idR bekommst du beim einfügen von Strings in ein Integer Feld keine Fehlermeldung - weil auch mysql dort wieder versucht den Typ zu konvertieren - und dann eben 0 rauskommt ...(ebenso bei Datumsfeldern, die haben dann eben 0000-00-00 als Inhalt) - also musst du die Daten in PHP prüfen (is_numeric und ähnliche Funktionen), weil aus einem Eingabefeld vom Typ "text" nunmal auch Strings rauskommen ..

        Ansonsten hat es natürlich Sinn die verschiedenen Spaltentypen zu verwenden, eben weil zum Beispiel mit einer Datetime - Spalte die Verwaltung von Daten "ganz automatisch" von statten geht - im Gegensatz zu einer Datumspalte als Varchar, wo du jedwede Umrechnung per Hand erledigen musst
        Zuletzt geändert von eagle275; 19.10.2010, 09:37.
        [font=Verdana]
        Wer LESEN kann, ist klar im Vorteil!
        [/font]

        Kommentar


        • #5
          Hallo,

          den Grund, der dich dazu gebracht hat, diese Funktion zu schreiben, kann ich nachvollziehen, allerdings haben dieses Problem andere Leute bereits vor langer Zeit gelöst und das auch noch sauber und sicher.

          Schau dir mal PHP: PDO - Manual an und besonders die Beispiele zu prepared statements.

          Gruß,

          Amica
          [COLOR="DarkSlateGray"]Hast du die [COLOR="DarkSlateGray"]Grundlagen zur Fehlersuche[/color] gelesen? Hast du Code-Tags benutzt?
          Hast du als URL oder Domain-Beispiele example.com, example.net oder example.org benutzt?
          Super, danke!
          [/COLOR]

          Kommentar

          Lädt...
          X