Update einer Chatfunktion

[dedlfix]

Tach!

Wenn du mit "echten" Prepared Statements solche meinst, die über das Binärprotokoll abgewickelt werden,

Ich meine damit Prepared Statements im Sinne des Erfinders und keine Emulation in einer Abstraktionsschicht, bei der im Hintergund doch wieder ein SQL-Statement daraus gebastelt wird.

ist es das selbe nur in grün. Auch beim Binärprotokoll muss dafür gesorgt, dass Nutzdaten nicht irrtümlich als Steuerdaten fehlinterpretiert werden. Für die Performance wird man aber wohl nicht auf Maskierung, sondern auf Längenangaben gesetzt haben.

Die Fehlinterpretation wird ausgeschlossen, wenn ein eindeutiges Protokoll verwendet wird. Die Längenangabe hat eine feststehende Länge, zum Beispiel 4 oder 8 Bytes. Diese Länge ist bekannt und muss nicht in Start- und Stopp-Zeichen/-Bytes eingerahmt werden. Danach folgen die Nutzdaten und die sind exakt die angegebene Länge an Bytes lang. Auch diese werden nicht in Start- und Stopp-Zeichen/-Bytes eingerahmt. Es besteht damit keine Notwendigkeit, diese nicht vorhandenen Start- und Stopp-Zeichen/-Bytes innerhalb der Nutzdaten zu kennzeichen/maskieren. Neben solchen variabel langen Daten (String, BLOB), die eine Längenangabe benötigen, gibt es auch noch solche, die eine feststehende Byteanzahl haben, wie alle Sorten von Integer und Fließkommabinärformate.

Im Gegensatz dazu arbeiten serialisierende Formate wie JSON. Die haben keine Längenangabe, sondern rahmen die Nutzdaten in Begrenzungszeichen ein, und dann braucht man Makierungen für diese Zeichen mit Sonderbedeutung. Es besteht aber keine Notwendigkeit, solche Serialisierungen zu verwenden, wenn der Übertragungsweg frei von menschlichem Eingriff ist oder keine unbekannten Systeme beteiligt sein können, die eventuell andere Binärformate für ihre Daten verwenden (also beispielsweise nicht die gängigen wie Zweierkomplement oder IEEE 754).

Für native Prepared Statements der menschenlesbaren SQL gilt was ich in meiner letzten Antwort geschrieben habe.

Was meinst du mit "native Prepared Statements der menschenlesbaren SQL"? Entweder sind Prepared Statements nativ/direkt/echt von der Datenbank, dem Treiber und der Abstraktionsschicht unterstützt oder sie werden emuliert. Deine Begriffswahl klingt für mich nach einem Widerspruch in sich.

dedlfix.