Verhalten des eindeutigen Index, der varchar-Spalte und (Leerzeichen)

8

Ich verwende Microsoft SQL Server 2008 R2 (mit dem neuesten Service Pack / Patches) und die Datenbanksortierung ist SQL_Latin1_General_CP1_CI_AS.

Der folgende Code:

%Vor%

führt zu folgenden Ergebnissen:

  

(1 Zeile (n) betroffen)

     

Msg 2601, Ebene 14, Status 1, Zeile 8

     

Kann keine doppelte Schlüsselzeile im Objekt 'dbo.Test' mit dem eindeutigen Index 'UniqueIndex' einfügen. Der doppelte Schlüsselwert ist (Beispiel).

     

Die Anweisung wurde beendet.

     

------------

     

& gt; Beispiel & lt;

     

(1 Zeile (n) betroffen)

Meine Fragen sind:

  1. Ich nehme an, der Index kann keine Leerzeichen speichern. Kann jemand mich auf offizielle Dokumentation verweisen, die dieses Verhalten spezifiziert / definiert?
  2. Gibt es eine Einstellung, um dieses Verhalten zu ändern, das heißt, es wird 'Sample' und 'Sample' als zwei verschiedene Werte erkannt (was sie übrigens sind), so dass beide im Index sein können.
  3. Warum auf der Erde gibt SELECT eine Zeile zurück? SQL Server muss mit den Leerzeichen in der WHERE-Klausel etwas wirklich Lustiges / Cleveres tun, denn wenn ich die Eindeutigkeit im Index entferne, werden beide INSERTs OK und SELECT zwei Zeilen zurückgeben!

Jede Hilfe / ein Zeiger in die richtige Richtung wäre willkommen. Danke.

    
Eric 27.02.2012, 06:01
quelle

1 Antwort

11

Nachgestellte Leerzeichen :

  

SQL Server folgt der ANSI / ISO SQL-92-Spezifikation (Abschnitt 8.2,   , Allgemeine Regeln # 3) zum Vergleichen von Strings   mit Leerzeichen. Der ANSI-Standard erfordert Auffüllen für das Zeichen   Zeichenfolgen, die in Vergleichen verwendet werden, damit ihre Längen vorher übereinstimmen   Vergleiche sie. Das Auffüllen wirkt sich direkt auf die Semantik von WHERE aus   und HAVING-Klausel Prädikate und andere Transact-SQL-Zeichenfolge   Vergleiche. Zum Beispiel berücksichtigt Transact-SQL die Zeichenfolgen 'abc' und   'abc' ist für die meisten Vergleichsoperationen gleichwertig.

     

Die einzige Ausnahme von dieser Regel ist das LIKE-Prädikat. Wenn das Recht   Die Seite eines LIKE-Prädikatausdrucks enthält einen Wert mit einem nachfolgenden Wert   Speicherplatz füllt SQL Server die zwei Werte nicht auf die gleiche Länge   bevor der Vergleich stattfindet. Weil der Zweck des LIKE   Prädikat, per definitionem, ist eher die Suche nach Mustern   als einfache String-Gleichheit Tests, dies verletzt nicht den Abschnitt   der ANSI SQL-92-Spezifikation, die bereits erwähnt wurde.

Hier ist ein bekanntes Beispiel für alle oben genannten Fälle:

%Vor%

Hier finden Sie weitere Details zu abschließenden Leerzeichen und der LIKE -Klausel .

Betreffende Indizes:

  

Ein Einfügen in eine Spalte, deren Werte eindeutig sein müssen, schlägt fehl, wenn Sie einen Wert angeben, der von vorhandenen Werten durch unterscheidet   nur nachstehende Leerzeichen. Die folgenden Strings werden alle berücksichtigt   gleichbedeutend mit einer eindeutigen Integritätsbedingung, einem Primärschlüssel oder einem eindeutigen Index.   Ebenso, wenn Sie eine vorhandene Tabelle mit den Daten unten haben und versuchen Sie es   fügen Sie eine eindeutige Einschränkung hinzu, es wird fehlschlagen, weil die Werte sind   als identisch angesehen.

%Vor%

(Aus hier .)

    
Oleg Dok 27.02.2012, 06:12
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset GeoDjango in einer NE, SW-Box