| 

.NET C# Java Javascript Exception

7
Hallo,

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)?

Viele Grüße

Silvia
News:
05.07.2012
Silvia1963 320 2 7
6 Antworten
4
Hallo Silvia,

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?
05.07.2012
kleffel 624 8
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 06.07.2012
@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
kleffel 07.07.2012
3
Ich bevorzuge eher GUID statt INT.

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.
05.07.2012
commänder 420 7
1
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.
09.07.2012
pistenprinz 121 3
1
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
12.07.2012
raffi 156 2 7
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

Read more: http://www.sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx#ixzz20OITemOD"

Es gibt keinen besseren Experten als Frau K. L. Tripp hier...
FrankHell 12.07.2012
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.
raffi 12.07.2012
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.
FrankHell 12.07.2012
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.
raffi 12.07.2012
Nochmal zum Mitlesen: 1.: Vorteil bei Replikationen (wie oben beschrieben).

Weitere NENNENSWERTE Vorteile?
FrankHell 12.07.2012
:o)
raffi 12.07.2012
Dachte ich mir... :o)
FrankHell 12.07.2012
Reicht das nicht?
sidekick 12.07.2012
??? 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.
raffi 12.07.2012
0
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.
06.08.2012
Magier77 238 6
-1
Auf keinen Fall GUID!

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.
11.07.2012
FrankHell 223 7
"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 ;-)
gfoidl 07.08.2012

Stelle deine Guid-Frage jetzt!