Was beachten beim einfügen eines Links in die DB

[portseven]

Tag,

kurze Frage,

sollte ich irgendetwas beachten wenn ich ein Link in die Datenbank speicher? Also zurzeit habe ich den Typ "TEXT" , Länge auf 200.

Mein PHP-Code

$link = $_POST['link']

$insert = $pdo->prepare("INSERT INTO data (link) VALUES (:link);");
$insert->BindParam(':link', $link);
if(!$insert->execute()) {
print_r($insert->errorInfo());
}

Eventuell Tipps oder Verbesserungsvorschläge?

[dedlfix]

Tach!

sollte ich irgendetwas beachten wenn ich ein Link in die Datenbank speicher?

Erst der Browser kann einen Link erzeugen. Was auch immer du konkret meinst ist entweder eine URL oder ein Stück HTML-Code. In beiden Fällen ist das nichts anderes als ein Stück Text. Du musst also nichts anderes beachten als für Text. Da du ein Prepared Statement verwendest, ist da auch nichts weiter zu tun.

Also zurzeit habe ich den Typ "TEXT" , Länge auf 200.

Warum TEXT und nicht VARCHAR?

Mein PHP-Code

$link = $_POST['link']

$insert = $pdo->prepare("INSERT INTO data (link) VALUES (:link);");
$insert->BindParam(':link', $link);
if(!$insert->execute()) {
print_r($insert->errorInfo());
}

Eventuell Tipps oder Verbesserungsvorschläge?

Das Umkopieren von $_POST['link'] in eine andere Variable ist überflüssig. $_POST['link'] lässt sich genauso verwenden wie $link. Das Umkopieren vergrößert deinen Code lediglich unnötigerweise. Wenn du etwas sinnvolles tun möchtest, musst du gemäß deinem Anwendungsfall prüfen, was das wäre. Vielleicht eine Prüfung auf Existenz und/oder eine Syntaxprüfung.

Da du vermutlich eine URL (und keinen HTML-Code) verarbeitest, wäre auch url statt link ein passenderer Name.

dedlfix.

[pl]

Tag,

kurze Frage,

sollte ich irgendetwas beachten wenn ich ein Link in die Datenbank speicher? Also zurzeit habe ich den Typ "TEXT" , Länge auf 200.

Genau darauf gilt es zu achten: Auf die Länge. Denn auch unter den Links gibt es lange Ottos 😉

Ansonsten sind URL's auch nur Text. Und sogar nur ASCII. Der Text zu einem Link kann jedoch in einer beliebigen Zeichenkodierung vorliegen.

MfG

[dedlfix]

Tach!

Ansonsten sind URL's auch nur Text. Und sogar nur ASCII.

Es gibt schon seit längerer Zeit die so genannten Umlaut-Domains. Das mit dem Nur-ASCII ist also Vergangenheit.

dedlfix.

[pl]

Tach!

Ansonsten sind URL's auch nur Text. Und sogar nur ASCII.

Es gibt schon seit längerer Zeit die so genannten Umlaut-Domains. Das mit dem Nur-ASCII ist also Vergangenheit.

Und auch die kann man als ASCII (Punycode) speichern, also gleich so wie sie auch intern verarbeitet werden.

MfG

[Matthias Apsel]

Hallo pl,

Und auch die kann man als ASCII (Punycode) speichern, also gleich so wie sie auch intern verarbeitet werden.

Muss man aber nicht.

Bis demnächst
Matthias

[pl]

hi,

Und auch die kann man als ASCII (Punycode) speichern, also gleich so wie sie auch intern verarbeitet werden.

Muss man aber nicht.

Hast Du schonmal programmiertechnisch mit Umlautdomains gearbeitet? Ich schon und von daher auch meine Empfehlung.

MfG

[dedlfix]

Tach!

Es gibt schon seit längerer Zeit die so genannten Umlaut-Domains. Das mit dem Nur-ASCII ist also Vergangenheit.

Und auch die kann man als ASCII (Punycode) speichern, also gleich so wie sie auch intern verarbeitet werden.

Mir fällt da grad nichts ein, warum ich sie für die interne Verabeitung in unschönen Punycode umwandeln müsste. Hast du da andere Anwendungsfälle als Speichern, die noch dazu Punycode benötigen würden? Zur Ausgabe an den 0815-Nutzer ist das jedenfalls auch nicht weiter geeignet. Erst wenn ich damit einen Request losschicken möchte, brauch ich die DNS-gerechte Form. Aber das ist ja nicht mehr intern.

dedlfix.

[pl]

Tach!

Es gibt schon seit längerer Zeit die so genannten Umlaut-Domains. Das mit dem Nur-ASCII ist also Vergangenheit.

Und auch die kann man als ASCII (Punycode) speichern, also gleich so wie sie auch intern verarbeitet werden.

Mir fällt da grad nichts ein, warum ich sie für die interne Verabeitung in unschönen Punycode umwandeln müsste.

CGI/1.1: Der Webserver setzt HTTP_HOST und SERVER_NAME in die Umgebung -- als Punycode. Bei einem multidomainfähigen FW ist das von Interesse weil das ohne Umschweife matchen muss, wenn der Request reinkommt, weiß man ja nicht ob das eine Umlautdomäne ist. MfG

[Robert B.]

Moin @portseven

sollte ich irgendetwas beachten wenn ich ein Link in die Datenbank speicher?

ja, eine sinnvolle Fehlerbehandlung. Das ist keine:

if(!$insert->execute()) {
print_r($insert->errorInfo());
}

Eventuell Tipps oder Verbesserungsvorschläge?

Zeig die SQL-Fehlermeldung lieber dem Entwickler und dem Nutzer den Hinweis, dass es nicht geklappt hat. Und dann sorge dafür, dass dein Programm an dieser Stelle nicht einfach weiter läuft.

Viele Grüße
Robert