none
GUID oder Text als Primärschlüssel?

    Frage

  • Hallo liebe Mitstreiter,

    ich stehe vor der Entscheidung, für eine Tabelle mit zukünftig wenigstens hunderttausenden Datensätzen ein vorhandenes Textfeld auf 25 Zeichen zu erweitern und als Primärschlüssel zu verwenden oder ein GUID-Feld als Primärschlüssel einzuführen.

    Hat jemand Erfahrung, wie sich die Zugriffszeiten in solchen Fällen verhalten? Wird voraussichtlich der Zugriff mit GUID oder mit Text schneller werden?

    Danke für eine Richtungsweisung.

    Mit freundlichen Grüßen

    Werner Muehlmann

    Freitag, 15. Juni 2012 13:20

Antworten

  • Hallo Stefan

    Stefan Hoffmann [MVP] wrote:

    Wenn es wirklich ein Textfeld oder ein GUID sein muss, dann ist die
    Verteilung wichtig. D.h. wenn dieser Schlüssel gleichzeitig der CLUSTERED
    INDEX ist, kann es zu entsprechender Fragmentierung kommen. Hier hilft
    bei einer GUID die FunktionNEWSEQUENTIALID()
    <http://msdn.microsoft.com/de-de/library/ms189786.aspx>.

    Wir befinden uns hier in der Access NG, bin vorhin auch darauf reingefallen. Wenn er nicht SQL Server Tabellen eingebunden hat, dann wird das so wohl nichts. In Access sind die GUIDs eher verpönt, nicht zuletzt weil diese in Jet eher mühsam gehandhabt werden müssen:
    http://trigeminal.com/lang/1033/codes.asp?ItemID=9#9

    Es bleibt allerdings die Frage braucht es überhaupt einen Ersatzschlüssel
    (surrogate key)? Und wenn ja, warum nicht ein INT oder BIGINT?

    BIGINT kennt Access ebenfalls nicht. ein Long (INT im SQL Server) wäre wohl der passende Datentyp.

    Ich würde dringend anraten, dass hier einfach das gemacht wird, was in der Regel eben gemacht wird: Ein Autowert Feld in der Tabelle anlegen und über dieses den Primärschlüssel definieren. Ist performant und einfach zu handhaben.

    Gruss
    Henry

    Montag, 18. Juni 2012 05:51

Alle Antworten

  • Wenn es wirklich ein Textfeld oder ein GUID sein muss, dann ist die Verteilung wichtig. D.h. wenn dieser Schlüssel gleichzeitig der CLUSTERED INDEX ist, kann es zu entsprechender Fragmentierung kommen. Hier hilft bei einer GUID die Funktion NEWSEQUENTIALID().

    Es bleibt allerdings die Frage braucht es überhaupt einen Ersatzschlüssel (surrogate key)? Und wenn ja, warum nicht ein INT oder BIGINT?

    Freitag, 15. Juni 2012 19:45
    Moderator
  • Hallo Stefan

    Stefan Hoffmann [MVP] wrote:

    Wenn es wirklich ein Textfeld oder ein GUID sein muss, dann ist die
    Verteilung wichtig. D.h. wenn dieser Schlüssel gleichzeitig der CLUSTERED
    INDEX ist, kann es zu entsprechender Fragmentierung kommen. Hier hilft
    bei einer GUID die FunktionNEWSEQUENTIALID()
    <http://msdn.microsoft.com/de-de/library/ms189786.aspx>.

    Wir befinden uns hier in der Access NG, bin vorhin auch darauf reingefallen. Wenn er nicht SQL Server Tabellen eingebunden hat, dann wird das so wohl nichts. In Access sind die GUIDs eher verpönt, nicht zuletzt weil diese in Jet eher mühsam gehandhabt werden müssen:
    http://trigeminal.com/lang/1033/codes.asp?ItemID=9#9

    Es bleibt allerdings die Frage braucht es überhaupt einen Ersatzschlüssel
    (surrogate key)? Und wenn ja, warum nicht ein INT oder BIGINT?

    BIGINT kennt Access ebenfalls nicht. ein Long (INT im SQL Server) wäre wohl der passende Datentyp.

    Ich würde dringend anraten, dass hier einfach das gemacht wird, was in der Regel eben gemacht wird: Ein Autowert Feld in der Tabelle anlegen und über dieses den Primärschlüssel definieren. Ist performant und einfach zu handhaben.

    Gruss
    Henry

    Montag, 18. Juni 2012 05:51
  • Autsch, manchmal sehe ich das nicht. Danke.
    Montag, 18. Juni 2012 07:33
    Moderator
  • Hallo Stefan, hallo Henry,

    danke für Eure Informationen. Was die Access NG betrifft, so sehe ich das für mich nicht so eng. Ich habe Stefans Hinweis schon richtig interpretiert.

    Die Daten sind derzeitig noch nicht in SQL, werden aber portiert. Es hat sich in den letzten Jahren, schon aus Synchronisationsgründen (ca. 140 verteilte Datenbanken), herausgestellt, dass ich mit GUID am besten liege. Die bisher verwendeten ganzzahligen Schlüssel halten den Anforderungen nicht stand. Mit GUID läuft es dagegen sehr gut. Ich werde also auf jeden Fall GUID verwenden.

    Allerdings muss zukünftig auf eine zusätzliche Tabelle, mit wenigstens einigen hunderttausend Datensätzen, zugegriffen werden, die zur Verfügung gestellt wird, und aus irgendeinem Programm wohl importiert wurde, vermutlich ohne Datenbankkenntnisse. Diese Tabelle, von der ich zur Zeit ein Musterexemplar mit knapp 200.000 Datensätzen zum Test habe, liegt der PrimaryKey als einziger Key auf einem Textfeld, 255 Zeichen lang...

    Da ich einen Index aus diese Tabelle übernehmen muss und ganzzahlige Indizes nicht verwenden kann/will, muss ich jetzt entscheiden, ob ich den vorhandenen Index, reduziert auf die maximale signifikante Feldlänge (nämlich diese 25 Zeichen), gleich verwende, oder eine GUID als eigentlichen Index in diese Tabelle einfüge. Beide, 25 Zeichen Text und GUID, sind genügend strukturiert, um sie ganzzahligen Indizes vorzuziehen.

    Mangels Erfahrung mit längeren Text-Indizes in großen Tabellen bleibt eigentlich nur die Frage, ob es bezüglich Performance Erfahrungen gibt: Text oder GUID?

    Mit besten Grüßen


    Werner Muehlmann

    Montag, 18. Juni 2012 11:36
  • Ich einen internen Ersatzschlüssel (Access Autowert, SQL Server IDENTIY) nehmen. Da Operationen auf Zahlen schneller sind als auf Texten. Das kann zu Geschwindigkeitsunterschieden führen, hängt aber vom Anwendungsszenario, d.h. Art der Abfrage, ab.

    Im speziellen gilt für den SQL Server:

    Wenn dieser Textschlüssel unstrukturiert ist oder die GUID zufallsverteilt ist, dann kann es bei großen Datenmengen zu unnotigen I/O-Operationen kommen. Siehe diesen Blog-Artikel.

    Montag, 18. Juni 2012 12:11
    Moderator
  • Hallo Stefan und nochmals vielen Dank, besonders für den Blog-Link.

    Die Diskussion im Blog zeigt ebenfalls, dass alles nicht nur eine Seite hat. Ich bin auch hin- und hergerissen. Aber aus all diesen Beiträgen entnehme ich, dass ich vermutlich mit GUID, deren Vorteile ich in diesem Fall einfach benötige, am besten fahre, bei allem Für und Wider, und den Textschlüssel, als vermutlich schlechtere Wahl, fallen lasse.

    Mit bestem Gruß


    Werner Muehlmann

    Mittwoch, 20. Juni 2012 05:26
  • Hallo Werner

    Was ist denn genau der Vorteil der GUID, den Du benötigst? Dass er unique über alle möglichen Systeme ist, die Du fütterst? Dann kannst Du auch gleich beim Text-Key bleiben.

    Gruss

    Henry

    Mittwoch, 20. Juni 2012 05:44