GUIDToString: welche Feldgrösse in der DB?

[Delbor]

Hi zusammen

Meine Bilddatenbank speicherte ursprünglich in der Bildtabelle neben JPEGs und BMPs auch RAW-Daten. Diese haben jedoch den Nachteil, das sie unbedingt in der Orignalgrösse vorliegen müssen. Je nach verwendetem Kameramodell sind das pro Bild 10MB, bzw. 24MB, wesshalb ich mich entschlossen hatte, diese Rohdaten nicht mehr in der DB, sondern wie bis anhin auf der (externen) Festplatte in einem speziellen Verzeichnis zu speichern.
Lade ich nun die Bilder aus diesem Ordner, lege ich in selbigem einen "IdentFolder" an, der als (zumindest bisher) einzige Datei einen mit GUIDToString erzeugten GUID enthält.
Damit will ich erreichen, das der entsprechende Ordner, wenn sein Inhalt mal eingelesen ist, auch dann noch eindeutig identifiziert werden kann, wenn sich der Pfad mal geändert haben sollte. Also wenn das externe Laufwerk plötzlich nicht mehr unter "D:/XXXX" (eingelesener Pfad in der DB) steht, sondern unter P:/DDDD" zu finden ist.

Mein Problem ist nun die Länge des Strings, respektive die notwendige Grösse des Feldes in der DB. Wikipedia gibt zwar die Länge des Strings mit 36 Zeichen an. Das aber kann unter Unicode zu wenig sein.

Meine Frage ist also ganz konkret: Welchen Datentyp weise ich diesem Feld unter MySQL am besten zu?
VarChar(36) ist da wohl nicht das richtige, auch wenn der Zeichensatz des Serveras utf8 ist?

Danke schonmal für eure Antworten!

Gruss
Delbor

[bernau]

Eine Guid besteht doch immer aus Buchstaben und Zahlen, die mit AnsiStrings abbildbar sind. Sollte dann doch mit der Größe keine Probleme geben.

[himitsu]

Erstmal, ist die GUID 16 Byte groß, wenn du sie "binär" speichern würdest.
Als String sind es 16*2 + 2 + 4 Zeichen (hexadezimale Zeichen, Klammern und die Trennstriche)

Also 38 Zeichen/Chars, 38 Byte als ANSI, 76 Byte als Unicode (UTF-16) und als UTF-8 304 Byte, da viele DBMS den Worst-Case annehmen und je Unicode-Char 4 UTF-8-CharsBytes reservieren.

PS: einige DBMS besitzen direkt einen GUID-DatenTyp.

[DeddyH]

Ich dachte immer, 36 Zeichen sind 36 Zeichen, ob ASCII, Ansi, UTF-8, UTF-16 oder meinetwegen irgendwelche klingonischen Kodierungen. Die Bytegröße mag sich unterscheiden, aber die Länge doch nicht.

[himitsu]

Ja, 36 Zeichen sind auch 36 Zeichen, aber vom "internen" Speicher her halt nicht.

DBMS arbeiten gern mit festen Größen.
36 Unicode-Zeichen brauchen immer 36*2 Byte.
Als ANSI, je nach CodePage 36 Byte oder mehr. (MultiByteZeichensätze)
UTF-8 ist im Prinzip "ANSI" mit der Codepage 65001.

UTF-8-Zeichen können bei "UCS2" bis zu 4 Byte pro Zeichen benötigen und wenn das DBMS jetzt eine feste Größe braucht/will, dann muß es von einem String mit maximaler Länger und mit den "schlimmsten" Unicode-Zeichen ausgehen.
MaxString := #65535#65535#65535#65535#65535#65535#65535#65535#65535#65535#65535#65535#65535#65535#65535#65535;

Voller UTF-16-Umfang (#0..#$10FFFF) ging bis zu 5 Byte in UTF-8 (glaub ich) und genau 2 Byte ohne und 4 Byte mit Surrogates im UTF-16.

[DeddyH]

Zitat von himitsu:

Ja, 36 Zeichen sind auch 36 Zeichen, aber vom "internen" Speicher her halt nicht.

DBMS arbeiten gern mit festen Größen.
36 Unicode-Zeichen brauchen immer 36*2 Byte.
Als ANSI, je nach CodePage 36 Byte oder mehr. (MultiByteZeichensätze)
UTF-8 ist im Prinzip "ANSI" mit der Codepage 65001.

UTF-8-Zeichen können bei "UCS2" bis zu 4 Byte pro Zeichen benötigen und wenn das DBMS jetzt eine feste Größe braucht/will, dann muß es von einem String mit maximaler Länger und mit den "schlimmsten" Unicode-Zeichen ausgehen.
MaxString := #65535#65535#65535#65535#65535#65535#65535#65535#65535#65535#65535#65535#65535#65535#65535#65535;

Voller UTF-16-Umfang (#0..#$10FFFF) ging bis zu 5 Byte in UTF-8 (glaub ich) und genau 2 Byte ohne und 4 Byte mit Surrogates im UTF-16.

Ein VACHAR(36) ist ein String mit bis zu 36 Zeichen Länge. Welcher Zeichensatz (und damit wieviel "interner" Speicher), das wird über die Collation (u.U. hintenrum über eine Domäne) festgelegt.

[Delbor]

Hi zusammen

Wie lese / verstehe ich das nun:

Zitat:

utf8 | UTF-8 Unicode | utf8_general_ci |

Mein Server steht aktuell auf utf8. Wenn ich das wirklich so verstehen kann, wie ich glaube, das zu verstehen, so kann der Server mit den Unicode-Strings von Delphi umgehen, was wiederum heisst, dass der Datentyp VARCHAR(36) auch OK wäre.
Allenfalls bliebe die Frage der Performance.
Nur mit Blick auf die Uhr "gemessen", ergab sich unter Win32(4MB) für ein Insert von gut 200 Fotos eine ungefähre Zeit von über 20 Minuten (mit Eintrag der RAW-Daten) gegenüber etwas mehr als 7 Minuten (Plus 2?) unter Win64/8MB (Ohne RAW-Eintrag).

Gruss
Delbor

[Stevie]

Eine GUID ist eine 128 Bit (16 Byte) Zahl und wird auch meist als solche gespeichert (siehe System.TGuid).
Wie sie dargestellt wird (oft im 8-4-4-4-12 Hexadezimalformat) ist eine andere Geschichte.

[Delbor]

Hi zusammen

Danke für eure ausführlichen Antworten!

Zitat:

Erstmal, ist die GUID 16 Byte groß, wenn du sie "binär" speichern würdest.

Zitat:

Eine GUID ist eine 128 Bit (16 Byte) Zahl und wird auch meist als solche gespeichert (siehe System.TGuid).

Demnach lege ich den Datentyp in der DB als 'VARBINARY(16)' fest. Soweit ich diese Seite trotz meines schlechten Englisch verstanden habe, kann dies ganz schön kompliziert sein (ausser bei Varbinary).

Gruss
Delbor

[Stevie]

Zitat von Delbor:

Demnach lege ich den Datentyp in der DB als 'VARBINARY(16)' fest. Soweit ich diese Seite trotz meines schlechten Englisch verstanden habe, kann dies ganz schön kompliziert sein (ausser bei Varbinary).

FireDAC bekommt das sehr leicht gehandelt, siehe http://codeverge.com/embarcadero.del...d-edit/1089150