Tabellennamen in der SQL funktioniert nicht mit Leerzeichen

[dedlfix]

Tach!

$sql = sprintf(
    'INSERT INTO `$1$s`.`%2$s` ('
    .' `Name`,'
    // ...
    .') VALUES ('
    ."'%3\$s',"
    // ...
    .')',
    // Werte alle erst noch SQL-gerecht escapen! SONST SLQ-INJECTION LÜCKE!!!
    $Datenbank,
    $Table,
    $Bezeichner,
    $Bild,
    // ...
);

Ja, "Werte alle erst noch SQL-gerecht escapen!". Aber Datenbank- und Tabellenname sind keine Werte. Die benötigen ein anderes Escaping, weil da ja der Backtick berücksichtigt werden muss und nicht die einfachen oder doppelten Anführungszeichen.

Ich arbeite mit der PDO-Erweiterung in PHP. Dort macht man das im Prinzip so:

$sql = sprintf(
    'INSERT INTO `:table` ('
    .' `Name`, `Bild`, `Hoch`, `Breit`, `Url`, `Infos`, `Daten`, `Datei`'
    .') VALUES ('
    .':bezeichner, :bild, :hoch, :breit, :adresse, :infos, :daten, :datei'
    .')';

$params = array(    
    ':bezeichner' => $Bezeichner,
    ':bild' => $Bild,
    ':hoch' => $Hoch,
    ':breit' => $Breit,
    ':adresse' => $Adresse,
    ':infos' => $Infos,
    ':daten' => $Daten,
    ':datei' => $Datei
);

Auf den ersten Blick fehlt in $params der Wert für table. Aber wenn man genau nachdenkt und obigen Punkt berücksichtigt, muss man zum Schluss kommen, dass das :table im Statement falsch ist. Einem Prepared Statement kann man nur Werte aber keine Bezeichner via Platzhalter übergeben.

Stell dir mal vor, eine Datenbankabstraktion würde Prepared Statements nur simulieren und dabei das SQL-Statement selbst zusammenbauen. Es müsste dann das Statement parsen und analysieren, um feststellen zu können, dass der eine Parameter da ein Tabellenname ist und anders behandelt werden muss. Das wäre eine Menge Arbeit und es wäre dann auch noch inkompatibel zu echten Prepared Statements.

dedlfix.