| 

.NET C# Java Javascript Exception

1
Ich stelle aktuell mein Application von Identity um, weil es sehr nervig ist, wenn ich erst nach der Anlage des Objekts in der Datenbank, dessen ID kenne.
Bekomme ich außer dem erhötem Speicheraufwand (x4) weitere Nachteile zu spüren?
Bieten sich mir auf der anderen Seite eventuell noch weitere Vorteile?
News:
08.09.2009
Price 13 1 4
3 Antworten
4
Nachteile:
1. Speicheraufwand
die maximale Größe eine Tabellenzeile bei MSSQL ist zum Beispiel auf 8KB limitiert
2. Lesbarkeit & Handling
zwar sind GUIDS sicherer weil man die folgende und vorherige nicht erraten kann, jedoch sind sie beim Debuggen, Entwickeln und der Fehlersuche umständlicher zu handhaben
Beispiel: "Fehler in Modul X - Line: 200 - Parameter: Foo=2557" läßt sich leichter per Telefon vom Endkunden durchgeben als "Fehler in Modul X - Line: 200 - Parameter: Foo={2D643CD0-10DF-4728-BBBA-89379F29A546}"

Vorteile:
1. Lesbarkeit & Handling
Was aus Debug- und Entwicklungssicht ein Nachteil ist, ist aus Sicherheitssicht ein Vorteil. ID's, deren Folge man nicht erraten kann, sind nicht so leicht zu manipulieren.
2. Erzeugen der ID's
Ein sehr interessanter Vorteil ist, dass sich GUID's auf Client-Seite erzeugen lassen.
Identitys werden immer auf Serverseite in Form von Autoincrements erzeugt und müssen anschließend mit @@Identity wieder gelesen werden. Jedoch kann @@Identity nicht den gewünschten Wert enthalten, wenn ein Tricker auf der Tabelle ebenfalls Inserts oder Updates durchführt. GUID's die direkt auf Clientseite erzeugt werden, brauchen nicht mittels @@Identity gelesen werden und unterliegen daher auch nicht deren Beschränkung.
Darüber hinaus lassen sich GUID's als Constanten innerhalb des SQL-Stamenets auf Serverseite erzeugen und unterliegen daher auch nicht den Beschränkungen von @@Identity. Aus Sicherheitssicht stellt es in meinen Augen kein großes Problem dar, wenn der Client die GUIDs zum einfügen in eine Tabelle erzeugt.

Abschließend:
Man sollte sich natürlich überlegen, wo der Einsatz von GUID's sinvoll ist und wo nicht.
Als Beispiel:

Create Table Personen(
ID uniqueidentifier not null,
Name varchar(100),
VName varchar(100),
Anrede uniqueidentifier,
Titel uniqueidentifier,
...
)

Create Table Anrede(
ID uniqueidentifier not null,
Anrede varchar(20),
r char(1),
e char(1),
...
)

Create Table Titel(
ID uniqueidentifier not null,
Titel varchar(20),
...
)


Eine Zeile in der Tabelle Personen verbraucht in der Form 24 Bytes mehr, als wenn Anrede und Titel von Datentyp Int und 30 Bytes mehr, als wenn sie vom Datentyp Tinyint wären.
Hier ist es also nicht sinnvoll, GUIDs zu verwenden; in diesem Fall wäre der zu bevorzugende Datentyp TinyInt (mehr als 255 Anreden wirst du nicht brauchen, denn meisten reichen Herr,Frau,Hermaphrodit und ggf. Firma).
08.09.2009
Floyd 14,6k 3 9
Floyd 14,6k 3 9
1
Nachteil MSSQL
Eine GUID als Key ist nicht brauchbar für einen clustered Index.
10.09.2009
BeachBlocker 617 3
weil? kannst du das etwas erläutern.
Rene Drescher-Hackel 12.09.2009
Ein Clustered Index funktioniert nur gut, wenn die Schlüssel in aufsteigender oder absteigender Reihenfolge eingefügt werden, aber nicht wenn die Schlüssel mehr oder weniger zufällige GUID sind.
BeachBlocker 15.04.2010
Wobei man mit entsprechenden Fülloptionen das Problem eigendlich entschärfen könnte.
Floyd 13.09.2010
0
Guids sind der einzig sinnvolle weg, wenn Du eine Anwendung schreibst, die nur gelegentlich mit dem Server Verbindung aufnimmt, ansonsten aber Offline arbeitet, da Du dann jederzeit eine dauerhaft eindeutige ID bekommst. Das wird selbst dann funktionieren, wenn es ein paar tausend Clients gibt.
09.09.2009
keinhaar 210 2 6
Das stimmt so nicht ganz. Es gibt weitere sinnvolle Anwendungsgebiete. Als Beispiel, wenn du ID's brauchst die nicht erratbar sind (autoincrements sind erratbar) welche man als Session-ID, LaufwerksID, VorgangsID ... verwenden kannst. Oder wenn du nicht die Möglichkeit hast dir eine Secquenzer für deinen Gültigkeitsbereich zu erzeugen (z.B. verteilte XML-Dokumente) .. und so weiter.
Floyd 13.09.2010

Stelle deine Sql-Frage jetzt!