Karsten F.: datatypes in sqlite - gute loesung

Hallo,

Gleich im Vorraus, ich arbeite mich in Datenbanken gerade ein und komme eher aus der XML Ecke.

Ich muss eine Menge XML Daten in eine sqlite Datenbank bringen. Nun bin ich daran, die Tabellen festzulegen. Jetzt meine Frage, ich wuerde gerne sehr lange URIs in eine kuerzere Form bringen und habe mich fuer md5 entschieden, allerdings sollen die hash werte spaeter beim auslesen als ID in xml Dokumenten dienen. Deshalb moechte ich immer noch einen Buchstaben ('m') dem hash Wert voranstellen, damit es eine valide ID fuer xml darstellt. Also etwa:

URI: http://shfsizjioejfoiwjeoifjoijoi/weuroiwu/rwowuer/ur/iwiourio#weuiuouo

umgewandelt in: m9e107d9d372bb6826bd81d3542a419d6

Nun meine Frage: Wie sollte der data type fuer eine solche id in sqlite 3.0 definiert werden? Und weiter, kann ich einen solchen wert als primary key nutzen (collision thema ausgeschlossen)?

Ware dankbar fuer Hinweise.

Gruss,K.

  1. Moin Moin!

    Ich muss eine Menge XML Daten in eine sqlite Datenbank bringen. Nun bin ich daran, die Tabellen festzulegen. Jetzt meine Frage, ich wuerde gerne sehr lange URIs in eine kuerzere Form bringen

    Warum? SQLite hat mit langen URIs überhaupt keine Probleme. Das Limit für Strings liegt soft (einstellbar) bei 10^9 Zeichen, hart (Strukturgrenzen) bei 2^31-1, rund 2*10^9 Zeichen.

    und habe mich fuer md5 entschieden,

    Schlechte Wahl. MD5 und alle anderen Hashing-Algorithmen haben immer Kollisionen. Und nach Murphy exakt dann, wenn Du sie am wenigsten brauchen kannst.

    allerdings sollen die hash werte spaeter beim auslesen als ID in xml Dokumenten dienen. Deshalb moechte ich immer noch einen Buchstaben ('m') dem hash Wert voranstellen, damit es eine valide ID fuer xml darstellt.

    Nimm einen Zähler oder noch besser eine Sequenz. Bei SQLite lautet die "Zauberformel" INTEGER PRIMARY KEY, andere Datenbanken haben AUTOINCREMENT, INTEGER IDENTITY oder echte Sequenzen.

    Also etwa:

    URI: http://shfsizjioejfoiwjeoifjoijoi/weuroiwu/rwowuer/ur/iwiourio#weuiuouo

    umgewandelt in: m9e107d9d372bb6826bd81d3542a419d6

    Why oh why?

    SQLite stört sich nicht an Strings mit mehr als 32 Zeichen.

    Nun meine Frage: Wie sollte der data type fuer eine solche id in sqlite 3.0 definiert werden?

    Es ist ein String. Mögliche Auswahl: String-Typen oder Binär-Typen. Wenn Du String-Operationen ausführen willst, nur String-Typen. Binär-Typen haben oft noch weitere Einschränkungen. Bleiben also nur String-Typen. Davon hat SQLite exakt einen.

    Und weiter, kann ich einen solchen wert als primary key nutzen

    Ja, wenn Du das wirklich willst, geht das. Aber ein einfacher Integer ist besser:

    (collision thema ausgeschlossen)?

    Wenn Du als PK eine Sequenze (INTEGER PRIMARY KEY) nimmst, machst Du der Datenbank (SQLite) die Arbeit wesentlich leichter. 64-Bit-Integer sind wesentlich leichter zu vergleichen als elend lange Strings. Und Kollisionen kommen stumpf nicht vor, bis Du mal 2^63 Einträge (SQLite Row IDs sind signed) in die DB-Tabelle geschrieben hast. (2^63 ist rund 10^19, das dauert also eine Weile.)

    Ware dankbar fuer Hinweise.

    Einen noch: [http://www.sqlite.org/docs.html@title=Categorical Index Of SQLite Documents]

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".