Bernd: Ist eine ID vom Typ varchar empfehlenswert?

Hallo,

für einen Kunden habe ich eine Datenbank erstellt, in die er "seine Objekte" (in diesem Fall Autos) einpflegen kann.
Ein Objekt hat eine ID-Nummer und einen ganzen Haufen Attribute.
Nun braucht er aber ein ID-Feld in das er sowohl Buchstaben, als auch Zahlen einfügen kann. Bisher habe ich immer nur integer-Werte als ID's benutzt, habe das so gelernt und bin dabei hängengeblieben.
In diesem speziellen Fall wäre es für mich aber extrem praktisch einfach in der DB (mySQL) das Feld ID vom Typ integer in den Typ varchar zu verändern.

Hat varchar irgendwelche Nachteile gegenüber integer als ID ?

Habt Ihr vielleicht einen anderen Vorschlag, bessere Idee, oder einen Datentyp der vielleicht besser passt ?

Ein paar Erfahrungsberichte wären nett.

mfg

Bernd

  1. Hi,

    Hat varchar irgendwelche Nachteile gegenüber integer als ID ?

    klar. So ist ein 8-Zeichen-Varchar beispielsweise 8 Byte groß, ein 8-Ziffern-Integer jedoch deutlich kleiner. Beides natürlich plus Overhead. Es hat aber auch Vorteile - so kann man beispielsweise nicht nur Ziffern darin speichern.

    Habt Ihr vielleicht einen anderen Vorschlag, bessere Idee, oder einen Datentyp der vielleicht besser passt ?

    Du hast schon Recht damit, dass man üblicherweise den Identifier als Zahlenfeld deklariert; auch aus Erfahrung. Wenn das aber bei euch nicht geht - und auch keine Extra-ID-Spalte mit einem Unique-Constraint auf die "bisherige" ID in Frage kommt - dann spricht zumindest nichts Grundsätzliches gegen eine Varchar-ID. Wenn ihr irgendwie könnt, macht es anders - wenn nicht, dann nehmt in Gottfrieds Namen Varchar.

    Cheatah

    --
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes
    1. hi,

      Du hast schon Recht damit, dass man üblicherweise den Identifier als Zahlenfeld deklariert; auch aus Erfahrung.

      da streiten sich die experten würde ich sagen. jedem sein heiliges schaf. manche setzen künstliche ids, manche nehmen die natürlichen objekt-bezeichner.

      dann spricht zumindest nichts Grundsätzliches gegen eine Varchar-ID.

      meiner meinung nach sind varchar schlechter als char, weil es langsamer ist und dass kann sich bei einem primary key bei grösseren datenbanken bemerkbar machen.

      Ilja

      1. hi,

        Tag!

        da streiten sich die experten würde ich sagen. jedem sein heiliges schaf. manche setzen künstliche ids, manche nehmen die natürlichen objekt-bezeichner.

        Eine ID wird zumeist nur Programm intern verwendet und nicht angezeigt (Typ <Zahl> - Autoincrement), um einen Datensatz wieder korrekt zusammenzufügen, wenn sich die Daten über mehrere Tabellen verteilen. Diese verteilung wird immer dann gemacht, wenn Werte Mehrfach vorkommen können. Das ist zum Beispiel bei Ortsnamen oder Strasen der Fall, denn man kann mehr als einen Kunden pro Ort und Strasse haben.

        Als Beispiel es Wohnen 500 Kunden von <Firma> in Hamburg. Eine durchdachte Datenbank lösung hätte jetzt nur ein einziges mal den String "Hamburg" im System - und keine 500 mal.

        Eine ID, die in einer Software angezeigt wird, wäre sowas wie die Artikelnummer, die dann zu einen Artikelsatz gehört, wo die zugehörige Bezeichnung, sowie eine Beschreibung und der Preis (unter umständen) drinn steht. Auch das wäre eine eigene Tabelle.

        Jedoch einen Bezeichner, wie z.B. "Mercedes SLK" als ID zu verwenden,
        ist nicht sehr Schick. Eine ID wird als Schlüssel verwendet - eine ID , die nicht irgendwo als Schlüssel verwendet wird, ist dann eigentlich keine ID mehr - aus Sicht der Datenbank natürlich.

        bye
        ich

        1. mahlzeit,

          Eine ID wird zumeist nur Programm intern verwendet und nicht angezeigt

          nö, id=identifier wird auch unabhängig von programmen benutzt, zum beispiel lateinische namen und bestimmte lebewesen zu benennen.

          (Typ <Zahl> - Autoincrement), um einen Datensatz wieder korrekt zusammenzufügen, wenn sich die Daten über mehrere Tabellen verteilen.

          nö, ein Datensatz verteilt sich nicht über mehrere tabelle, sondern steht in einer. sonst wäre es ja nicht ein datensatz.

          Diese verteilung wird immer dann gemacht, wenn Werte Mehrfach vorkommen können.

          nö, die aufteilung in mehrere tabellen (normalisierung) ergibt sich aus den abhängigkeiten zum primary key und ist somit unabhängig von dem inhalt der datenfelder.

          Als Beispiel es Wohnen 500 Kunden von <Firma> in Hamburg. Eine durchdachte Datenbank lösung hätte jetzt nur ein einziges mal den String "Hamburg" im System - und keine 500 mal.

          nö, würde ich so nicht machen. das kann man machen, aber ich würde in diesem falle darauf verzichten. stell dir mal vor, es gibt viele kunden aus kleinen orten in der nähe von hamburg. aus diesen kleinen orten sind jeweils nur 1 bis 3 kunden. warum sollte ich dann diese in eine extra tabelle aufteilen und damit meine datenbank langsamer machen, nur um jedes kleine pupdorf in einer extra tabelle aufzulisten ?
          oder anders ausgedrückt, der name müller kommt bei den 500 kunden 50 mal vor, ziehst du den dann auch in eine extra tabelle ?

          Eine ID, die in einer Software angezeigt wird, wäre sowas wie die Artikelnummer, die dann zu einen Artikelsatz gehört, wo die zugehörige Bezeichnung, sowie eine Beschreibung und der Preis (unter umständen) drinn steht. Auch das wäre eine eigene Tabelle.

          eine artikelnummer kann auch der eindeutige bezeichner einer tabelle sein und man benötigt nicht immer eine zahl als id. das nennt sich dann ein natürlicher schlüssel. solange er die bedingungen eines primary keys erfüllt (eindeutig ist, was artikelnummer von defintion her an sich haben), ist alles roger.

          Jedoch einen Bezeichner, wie z.B. "Mercedes SLK" als ID zu verwenden,
          ist nicht sehr Schick.

          der einzige, der von solchen ids spricht bist du und nicht ich. artikelnummern ist generell etwas anderes als dein mercedes und erfüllt alle anvorderungen eines schlüssels. lies dir noch einmal die anvorderungen an einen primary key durch. da wirst du nichts von "nur zahlen" finden.

          Eine ID wird als Schlüssel verwendet - eine ID , die nicht irgendwo als Schlüssel verwendet wird, ist dann eigentlich keine ID mehr - aus Sicht der Datenbank natürlich.

          und was willst du damit ausdrücken ?

          amen
          Ilja

      2. Hello,

        meiner meinung nach sind varchar schlechter als char, weil es langsamer ist und dass kann sich bei einem primary key bei grösseren datenbanken bemerkbar machen.

        Wieso sollten VarChar langsamer als Char sein? Die Längendefinition wird nur einmal am Anfang eingelesen. Und sie ist kontant für die gesamte Tabelle.

        Tinytext und Text und Blob sind langsamer, da sie intern nicht in der selben Tabelle (aber selbe Datei) gespeichert werden. Das macht bis Faktor 10 aus. Habe ich intensive Tests zu gemacht.

        Probleme kann es nur mit der Sortierung solcher Schlüssel geben, da sie von der (alternate) collating sequence, sprich der eingestellten Sortiertabelle und dem Zeichensatz abhängig sind.

        Alle Zeichenschlüssel könnten daher langsamer als Numerische Schlüssel sein. Numerische können direkt als Index in die Datenstruktur (Index*Satzlänge => Einsprungspunkt) dienen.

        Grüße

        Tom

        1. hi,

          Wieso sollten VarChar langsamer als Char sein? Die Längendefinition wird nur einmal am Anfang eingelesen. Und sie ist kontant für die gesamte Tabelle.

          meiner meinung nach ist die länge einer solchen spalte variabel, je nachdem wie lang der string ist. ich lasse mich aber gerne eines besseren belehren.

          Tinytext und Text und Blob sind langsamer, da sie intern nicht in der selben Tabelle (aber selbe Datei) gespeichert werden. Das macht bis Faktor 10 aus. Habe ich intensive Tests zu gemacht.

          wer spricht von tinytext, text oder blob ?

          Alle Zeichenschlüssel könnten daher langsamer als Numerische Schlüssel sein. Numerische können direkt als Index in die Datenstruktur (Index*Satzlänge => Einsprungspunkt) dienen.

          es ging mir nicht darum, zwischen numerischen und nicht numerischen primary keys zu unterscheiden, sondern zwischen char und varchar. und wenn mich nicht alles täuscht, dann dient der index nicht immer auch als errechnete sprungadresse.

          Ilja

  2. Hallo,

    für einen Kunden habe ich eine Datenbank erstellt, in die er "seine Objekte" (in diesem Fall Autos) einpflegen kann.
    Ein Objekt hat eine ID-Nummer und einen ganzen Haufen Attribute.
    Nun braucht er aber ein ID-Feld in das er sowohl Buchstaben, als auch Zahlen einfügen kann. Bisher habe ich immer nur integer-Werte als ID's benutzt, habe das so gelernt und bin dabei hängengeblieben.
    In diesem speziellen Fall wäre es für mich aber extrem praktisch einfach in der DB (mySQL) das Feld ID vom Typ integer in den Typ varchar zu verändern.

    Hat varchar irgendwelche Nachteile gegenüber integer als ID ?

    Habt Ihr vielleicht einen anderen Vorschlag, bessere Idee, oder einen Datentyp der vielleicht besser passt ?

    Ein paar Erfahrungsberichte wären nett.

    mfg

    Bernd

    Hallo Bernd,

    Du kannst ja eine Zwischentabelle machen, in der du den Integer-ID's einen Char-Wert als Schlüssel zuordnest.

    Als AutoWert wird das nicht klappen.

    Grüße,

    Wolfram

    1. Hi,

      Du kannst ja eine Zwischentabelle machen, in der du den Integer-ID's einen Char-Wert als Schlüssel zuordnest.

      eine 1:1-Beziehung? Das relationale Konzept dafür nennt sich "Spalte", nicht "Tabelle".

      Cheatah

      --
      X-Will-Answer-Email: No
      X-Please-Search-Archive-First: Absolutely Yes
  3. hi Bernd,

    Nun braucht er aber ein ID-Feld in das er sowohl Buchstaben, als auch Zahlen einfügen kann.

    was er sieht muss ja nicht das sein, was auch ist, sprich du kannst deine gewohnte int IDs führen und in einer zusätzliche spalte seine objektbezeichung, wobei jedes für sich ein eindeutiger schlüssel wäre.

    In diesem speziellen Fall wäre es für mich aber extrem praktisch einfach in der DB (mySQL) das Feld ID vom Typ integer in den Typ varchar zu verändern.

    möglich, ich würde aber nicht varchar sondern char typen nehmen, einfach weil es schneller ist.

    Ilja

    1. Hello,

      was er sieht muss ja nicht das sein, was auch ist, sprich du kannst deine gewohnte int IDs führen und in einer zusätzliche spalte seine objektbezeichung, wobei jedes für sich ein eindeutiger schlüssel wäre.

      Das wäre aber ein eindeutiger Verstoß gegen die Grundlagen der Datenbank-Kunde. Zwei Schlüssel, die direkt voneinander abhängig sind, sollten nicht vorkommen.

      Grüße

      Tom

      1. hi,

        Das wäre aber ein eindeutiger Verstoß gegen die Grundlagen der Datenbank-Kunde. Zwei Schlüssel, die direkt voneinander abhängig sind, sollten nicht vorkommen.

        wer sagt den, dass ich auch beide als primary key deklarieren würde. nimmt man beides rein, ist alleine die id der primary key. alles was ich zum audruck bringern wollte ist, dass sowohl die id nummer als auch die artikelnummer alle bedingungen eines keys erfüllen.

        gruß
        Ilja

  4. hi,

    für einen Kunden habe ich eine Datenbank erstellt, in die er "seine Objekte" (in diesem Fall Autos) einpflegen kann.
    Ein Objekt hat eine ID-Nummer und einen ganzen Haufen Attribute.
    Nun braucht er aber ein ID-Feld in das er sowohl Buchstaben, als auch Zahlen einfügen kann.

    der _kunde_ braucht ...?

    nein, tut er nicht. eine ID ist dazu da, den datensatz in der tabelle eindeutig identifizieren zu können, punkt.

    wenn er irgendwelche kennzeichen eingeben will, die nur für ihn eine bedeutung haben, nicht aber für die datenbank, dann richte dafür eine zusätzliche spalte ein.

    gruss,
    wahsaga

    1. Hallo,

      der _kunde_ braucht ...?

      Braucht er, ja.

      nein, tut er nicht. eine ID ist dazu da, den datensatz in der tabelle eindeutig identifizieren zu können, punkt.

      Wiederspricht sich nicht mit den Wünschen des OP.

      wenn er irgendwelche kennzeichen eingeben will, die nur für ihn eine bedeutung haben, nicht aber für die datenbank, dann richte dafür eine zusätzliche spalte ein.

      Teilweise richtig. Wenn es Kennzeichen sind, die eindeutig sind, dann richte ein VARCHAR ein und mach einen Primärschlüssel draus.

      Peter

      1. Hello,

        ich vor Jahren mal eine Applikation für den Kraftfahrzeughandel und -Reparatur geschrieben. Da kam als Erfahrung dabei heraus, dass Kraftfahrzeuge wandern. Außerdem sind ihre Einzelteile zum großen Teil auch mit Primärschlüsseln versehen. Teilweise treten dadurch vermeintliche Redundanzen auf.

        • KFZ-Kennzeichen , ist temporär an das Fahrzeug gebunden
        • KFZ-Typ, kann auch wechseln z.B. von BUS zu PKW oder
                     von PKW zu LKW, oder...
        • Motornummer
        • Fahrgestellnummer
        • Kundennummer
        • Farbnummer
          ...

        Wahsaga hat also in gewisser Weise Recht, dass man einen eineindeutigen Schlüssel nur durch künstlichen Primary Key erzeugen kann. Allerdings besteht dann hier auch die philosophische Frage:

        Darf das KFZ diesen Schlüssel behalten, wenn alle Teile gleich bleiben, außer dem Fahrgestell? Oder geht der Schlüssel mit dem Fahrgestell unter? Dann wäre er unerlaubt redundant, weil direkt abhängig von der Fahrgestellnummer. Man könnte dann gleich die Fahrgestellnummer benutzen.

        Es empfiehlt sich ggf. als Primary Key einen zusammengesetzten Schlüssel zu verwwenden, z.B. aus Fahrgestell- und Motornummer.

        Dies sind die meist relevanten Kenngrößen eines KFZ.

        Gegen Alphanumerische Schlüssel ist aber im Grundsatz überhaupt nichts einzuwenden. Aber achte darauf, ob Groß-/Kleinschreibung eine Rolle spielen muss. Das ist eine beliebte Falle.

        Grüße

        Tom

        1. Hallo Tom,

          Darf das KFZ diesen Schlüssel behalten, wenn alle Teile gleich bleiben, außer dem Fahrgestell? Oder geht der Schlüssel mit dem Fahrgestell unter? Dann wäre er unerlaubt redundant, weil direkt abhängig von der Fahrgestellnummer.

          Wieso »unerlaubt«? Wenn dies der Fall ist, dann erfüllt das Datenmodell irgendeine Normalform nicht. Das hat aber nichts damit zu tun, ob das erlaubt ist, oder nicht. Und inwieweit jemand normalisieren will, bleibt jedem selbst überlassen.

          Viele Grüße,
          Christian

        2. Hi,

          Es empfiehlt sich ggf. als Primary Key einen zusammengesetzten Schlüssel zu verwwenden, z.B. aus Fahrgestell- und Motornummer.

          m.E. empfiehlt es sich die benoetigte Eindeutigkeit mit einem bedeutungsfreien nicht zusammengesetztem Datenfeld zu erzeugen und spaeter dann zu hegen und zu pflegen. - Alles andere bringt nach meiner Erfahrung Pech.

          Gruss,
          Lude

          PS: Die Fahrgestell-ID ist die Auto-ID? - Schade, mein Fahrzeugschein gerade nicht dabei.   ;-)

  5. Hallo,

    eieiei, viele Meinungen auf einen Haufen.
    Was kann ich daraus schließen ?
    Es wurde nicht einmal ein wirklicher Grund gegen vachar bzw. char genannt, außer die Geschwindigkeitunterschiede, die bei einer Seite die 2 gb traffic im monat hat wohl nicht so sehr ins Gewicht fallen.

    Können vielleicht andere Probleme auf mich zukommen, wenn ich keine Integer benutze, oder ists bloß der Geschwindigkeitsunterschied oder die saubere Art zu programmieren :D ?

    mfg

    Bernd