was ist eher "best practice"? In einer Tabellen-Beziehung Kunde --> Auftrag der Tabelle Kunde einen Primärschlüssel als GUID oder als ID (Autowert) zu geben?
Als welcher Datentyp würde denn GUID später in .NET dargestellt werden (Entity Framework)?
ich bin im Normalfall eher für INT IDENTITY. Wenn man mal in die DB reinschaut, empfinde ich das besser vom Handling. Aber prinzipiell spricht doch auch nichts gegen GUID.
Wenn man die Daten mit anderen Systemen austauschen muss, ist GUID evtl. besser.
Kann Entity Framework GUID nicht als Datentyp mappen? Das ist doch in .NET identisch?
Wir haben unsere DB alle auf GUID umgestellt, da wir dadurch die Möglichkeit haben, mit unseren Entwicklungs-DB Einträge zu erstellen, die dann in das Live-System eingespielt werden können. Wenn es die fortlaufende Nummer ist, mussten wir immer die aktuelle DB sperren - unsere Anpassungen machen - dann wieder freigeben
@MyKey0815 sehe ich auch so, dass GUID dann besser ist. Bei Replikation und INT IDENTITY gäbe es aber auch eine Möglichkeit: reseed. Allerdings geht das nur, wenn nicht zu viele verschiedene DBs vorliegen, sonst wird die Range von Identity zu klein
Der Vorteil ist, dass die GUID's einfach erzeugt werden können, ohne Konflikte mit doppelten GUID's zu bekommen, speziell dann wenn sich irgendwann mal die Software-Spezifikationen dahingehend ändern, dass man offline-fähig sein muss, Synchronisation zwischen verschiedenen Servern oder PCs, etc.
Auch wenn man irgendwann mal vorhat, mit der SQL Server Replikation zu arbeiten, dann sind die GUID's AFAIK unumgänglich (auch wenn ich mich damit noch nicht beschäftigt habe).
Klar, GUIDs sind in Abfragen schwer lesbar, aber dann macht man halt mal schnell nen JOIN auf die dazugehörigen Stammdaten oder Klarnamen, und fertig.
Spricht aus performance-Gründen nicht eigentlich alles für INT-IDs? Zumindest haben wir aus diesen Gründen alle Guids durch INT-IDs ersetzt. Bei sehr großen Datenmengen machte sich das extrem bemerkbar.
Es gibt kein richtig oder falsch, sondern passt zu meiner Anwendung oder passt nicht. Vor- und Nachteile kann man hier nachlesen: Primary Keys: IDs versus GUIDs
Es gibt aber hier ein "Besser" und "Schlechter". Und die GUID-Idee ist einfach schlecht. Das ist Fakt. Siehe hier: "But, a GUID that is not sequential - like one that has it's values generated in the client (using .NET) OR generated by the newid() function (in SQL Server) can be a horribly bad choice
Kimberly L. Tripp erwähnt in dem Artikel aber auch NEWSEQUENTIALID(). Hier gibt es weitere Informationen: http://sqlpractice.wordpress.com/2010/04/08/sql-server-newid-versus-newsequentialid/ Auch wenn du in K. L. Tripp deine persönliche Göttin gefunden hast, gibt es Szenarien, für die eine GUID besser geeignet ist. Siehe hierzu meinen ersten Link.
Zusammengefasst sagt der erste Artikel, dass GUIDs lediglich bei datenbankübergereifenden Transaktionen (z.B. Replikation) hilfreich sein können. Mehr wesentliche Vorzüge gibt es nicht. Die Nachteile überwiegen hier schlicht. Basta.
Siehst du das nicht als mögliches Szenario für eine Software? Z.B. Mergen von Datenbanken unterschiedlicher Fillialen, ... Da fallen mir einige Anwendungsfälle ein.
??? Hm, das von mir beschriebene Szenario ist ein nennenswerter Vorteil. Daher verteufle ich GUIDs nicht per se. Was mich stört sind Aussagen wie "Auf keinen Fall", wenn es durchaus, z. B. bei Replikationen, Sinn macht. Auch "Basta" lässt keine anderen Meinungen zu. Dem ist hier definitiv nicht so. Daher bedeutete der Smilie nicht "ich weiß nicht weiter", sondern "hier brauch ich nicht weiter diskutieren". Daher von mir EOT.
So gruselig GUIDs auch sein mögen, Aussagen wie "auf keinen Fall" würde ich mit Vorsicht genießen. Wir stehen gerade vor der wundervollen Aufgabe zwei separate Kundensysteme mit dutzenden Tabellen zu einem zusammenzuführen, in denen int PKs genutzt wurden... es gibt wirklich schöneres. Hätten zumindest die Tabellen GUIDs als PK, in denen die Kundendaten stecken, wäre das ein Klacks. Es ist also durchaus erlaubt darüber nachzudenken, andere, siehe sämtliche in vorherigen Beiträgen genannte Links, tun es ja schließlich auch. Insofern volle Zustimmung zum Beitrag von kleffl.
INT/BIGINT IDENTITY ist besser. Der (gruppierte bzw. clustered) Primärschlüssel sollte immer fortlaufend sein, damit der Index einfach fortgeschrieben werden kann. Bei GUIDs muss der gesamte Index-Baum (B-Tree) umorganisiert werden, wenn neue Datensätze hinzukommen! Das verursacht unötigen Aufwand bei den DML-Aktionen (Delete/Insert) und ist bei INT einfach geringer.
"Primärschlüssel sollte immer fortlaufend sein" stimmt, daher gibt es auch sequentielle GUIDs und somit zieht dein Argument für INT/BIGINT nicht mehr ;-)
