Confronto tra maiuscole e minuscole in SQL Server

Question

Quali sono i vantaggi/svantaggi dell'utilizzo di regole di confronto senza distinzione tra maiuscole e minuscole in SQL Server (in termini di prestazioni di query)?

Ho un database che attualmente utilizza un confronto senza distinzione tra maiuscole e minuscole e non mi piace molto. Mi piacerebbe molto cambiarlo in maiuscole e minuscole. Di cosa dovrei essere a conoscenza quando si cambiano le regole di confronto?

Answer 1

(ho aggiunto questo come una risposta separata perché la sua sostanzialmente diversa rispetto al mio primo.) Ok, ho trovato della documentazione vera e propria. Questo MS KB article dice che ci sono differenze di prestazioni tra diverse regole di confronto, ma non dove si pensa. La differenza è tra confronti SQL (compatibile con le versioni precedenti, ma non Unicode a conoscenza) e di Windows collations (unicode consapevoli):

In generale, il grado di differenza di prestazioni tra le finestre e le regole di confronto di SQL non sarà significativo. La differenza appare solo se un carico di lavoro è vincolato alla CPU, piuttosto che essere vincolato da I/O o dalla velocità della rete, e la maggior parte di questo carico di CPU è causato dal sovraccarico della manipolazione delle stringhe o dei confronti eseguiti in SQL Server.

Sia le regole di confronto SQL che quelle di Windows hanno la distinzione tra maiuscole e minuscole e maiuscole e minuscole, quindi sembra che non sia la preoccupazione principale.

Un'altra bella storia "dalle trincee" in eccellente articolo di Dan intitolato "Collation Hell":

ho ereditato un ambiente collazione mescolato con più regole di confronto che posso contare su una mano. Le diverse regole di confronto richiedono soluzioni alternative per evitare errori di "impossibile risolvere conflitti di confronto" e tali soluzioni alternative eliminano le prestazioni a causa di espressioni non sargable. Affrontare le mescolanze miste è un vero dolore quindi ti raccomando caldamente di standardizzare su una singola fascicolazione e di deviare solo dopo un'attenta riflessione.

E conclude:

Io personalmente non credo che le prestazioni dovrebbe nemmeno essere presa in considerazione nella scelta del corretto collazione. Uno dei motivi per cui sto vivendo in conflitto è che i miei predecessori hanno scelto le regole binarie per ricavare ogni aspetto delle prestazioni dei nostri sistemi OLTP altamente transazionali. Con la sola eccezione di una ricerca di scansione di tabelle jolly leader, non ho riscontrato differenze di prestazioni misurabili con le nostre diverse regole di confronto. La vera chiave per le prestazioni è l'ottimizzazione di query e indici piuttosto che le regole di confronto. Se le prestazioni sono importanti per te, ti consiglio di eseguire un test delle prestazioni con le domande di domanda effettive prima di scegliere una collazione basata sulle aspettative di rendimento.

Spero che questo aiuti.

Answer 2

Direi che la più grande svantaggio di passare a un metodo di confronto sensibile caso in un database di produzione sarebbe che molti, se non la maggior parte, delle vostre domande fallirebbe in quanto sono attualmente concepite per ignorare caso.

Non ho provato a modificare le regole di confronto su un database esistente, ma ho il sospetto che potrebbe richiedere anche molto tempo. Probabilmente dovrai bloccare completamente i tuoi utenti mentre avviene anche il processo. Non provarlo a meno che tu non abbia provato a fondo su dev.

Answer 3

Se si modificano le regole di confronto sul database, è inoltre necessario modificarlo singolarmente su ciascuna colonna: mantengono l'impostazione di confronto che era in vigore al momento della creazione della tabella.

create database CollTest COLLATE Latin1_General_CI_AI 
go 
use CollTest 
go 
create table T1 (
    ID int not null, 
    Val1 varchar(50) not null 
) 
go 
select name,collation_name from sys.columns where name='Val1' 
go 
alter database CollTest COLLATE Latin1_General_CS_AS 
go 
select name,collation_name from sys.columns where name='Val1' 
go 

Risultato:

name collation_name 
---- -------------- 
Val1 Latin1_General_CI_AI 

name collation_name 
---- -------------- 
Val1 Latin1_General_CI_AI 

Answer 4

Se si modifica la regola di confronto del database, ma non il server collazione (e quindi non corrispondono di conseguenza), attenzione quando si utilizzano tabelle temporanee. Salvo diversamente specificato nella loro dichiarazione CREATE, utilizzeranno le regole di confronto predefinite del server piuttosto che quelle del database che potrebbero causare JOIN o altri confronti con le colonne del DB (presupponendo che vengano anche modificati alle regole di confronto del DB, come accennato da Damien_The_Unbeliever) fallire.

Answer 5

non riesco a trovare nulla di confermare se adeguatamente costruiti query lavorare più velocemente su una base di dati vs case-insensitive maiuscole e minuscole (anche se ho il sospetto che la differenza è trascurabile), ma alcune cose sono chiare per me:

1. Se le vostre esigenze di business non chiedono per esso, si sta mettendo da soli fino a un sacco di lavoro extra (questo è il punto cruciale sia HLGEM e risposte di Damien_The_Unbeliever).
2. Se i requisiti aziendali non lo richiedono, ti stai preparando per un sacco di possibili errori.
3. il suo modo troppo semplice per creare query scarso rendimento in un database case-insensitive se un caso è richiesto sensibili ricerca:

una query come:

... WHERE UPPER(GivenName) = 'PETER' 

sarà non utilizzare un indice su GivenName. Si potrebbe pensare qualcosa:

... WHERE GivenName = 'PETER' COLLATE SQL_Latin1_General_CP1_CS_AS 

funzionerebbe meglio, e lo fa. Ma per ottenere il massimo delle prestazioni che avrebbe dovuto fare qualcosa di simile:

... WHERE GivenName = 'PETER' COLLATE SQL_Latin1_General_CP1_CS_AS 
    AND GivenName LIKE 'PETER' 

(vedi this article per i dettagli)