2010-04-26 14 views
10

Diciamo che ho una tabella che ha un campo varchar. Se faccio un inserto in questo modo:c'è uno svantaggio nel mettere N davanti alle stringhe negli script? È considerata una "migliore pratica"?

INSERT MyTable 
SELECT N'the string goes here' 

C'è qualche differenza fondamentale tra questo e:

INSERT MyTable 
SELECT 'the string goes here' 

La mia comprensione è che devi avere un problema solo se la stringa contiene un carattere Unicode e la colonna di destinazione non era unicode. Oltre a ciò, SQL si occupa di esso e converte la stringa con lo N'' in un campo varchar (in pratica ignora lo N).

Ho avuto l'impressione che lo N di fronte alle stringhe fosse una buona pratica, ma non riesco a trovare alcuna discussione che consideri definitiva.

risposta

3

Risposta breve: bene per gli script, male per il codice di produzione.

Non è considerata una buona pratica. C'è un rovescio della medaglia, crea un minuscolo successo di prestazioni quando i caratteri da 2 byte vengono convertiti in caratteri da 1 byte.

Se non si sa dove sta andando l'inserimento, o non si sa da dove proviene il testo sorgente (si supponga che si tratti di un'utilità di inserimento dati generica che genera istruzioni di inserimento per un obiettivo sconosciuto, ad esempio durante l'esportazione dati), N'foo 'potrebbe essere lo stile di codifica più difensivo.

Quindi il lato negativo è piccolo e il lato positivo è che il codice dello script è molto più adattabile alle modifiche nella struttura del database. Questo è probabilmente il motivo per cui lo vedi in grandi quantità di script di inserimento dati.

Tuttavia, se il codice in questione è qualcosa che si intende riutilizzare in un ambiente in cui ci si preoccupa della qualità del codice, non si dovrebbe utilizzare N'the string' perché si sta aggiungendo una conversione in cui nessuno è necessario.

+1

Ah, sulla difensiva, mi piace quel termine qui. +1 – jcollum

+0

Penso che questo, combinato con quello sopra è la risposta. Penso che modificherò questo e lo chiamerò la risposta. – jcollum

+0

@jcollum: non si tratta solo del successo in termini di prestazioni di una conversione. Stai indicando la semantica sbagliata ai futuri manutentori. È un po 'come scrivere predicati come 'WHERE SomeCol =' 1'', come se fosse una colonna' varchar', quando è davvero una colonna 'int'. Potrebbe funzionare, ma ciò non lo rende meno sbagliato e potrebbe portare a errori di confronto in futuro, man mano che lo script viene modificato. Ovviamente il codice generato non è considerato uno standard di qualità elevato come il codice scritto; lo stesso è generalmente vero per qualsiasi codice gen, prova a guardare il codice sottostante del designer di un Windows Form. – Aaronaught

6

È necessario inserire come prefisso le stringhe con N quando sono destinate a una colonna o parametro nvarchar(...). Se sono destinati a una colonna o parametro varchar(...), quindi ometterlo, altrimenti si finisce con una conversione non necessaria.

Non è sicuramente una "best practice" attenersi a N di fronte a ogni stringa indipendentemente da cosa sia.

+1

Ma se si mette l'N di fronte, non è necessario sapere quale sia il tipo di dati della colonna di destinazione. Preoccuparsi per la conversione extra sembra una micro-ottimizzazione. – jcollum

+2

@jcollum: resta il fatto che la pratica migliore consiste nell'utilizzare ciò che è effettivamente corretto. Qualcuno potrebbe esaminare la tua query e concludere in modo errato che la colonna supporti caratteri Unicode quando in realtà non lo è. – Aaronaught

+0

Quello che mi chiedo allora è perché così tanti strumenti mettono N davanti alle stringhe, indipendentemente dal tipo di destinazione. – jcollum

0

Da INSERT (Transact-SQL)

Quando si fa riferimento ai tipi di dati Unicode carattere nchar, nvarchar e ntext, 'espressione' deve essere preceduto da la lettera maiuscola 'N'.

hanno anche una lettura a Why do some SQL strings have an 'N' prefix?

E

Server-Side Programming with Unicode

costanti stringa Unicode che appaiono nel codice eseguito sul server, come ad come in stored procedure e trigger, deve essere preceduto dalla lettera maiuscola N. Questo è vero anche se la colonna a cui si fa riferimento è già definito come Unicode . Senza il prefisso N, la stringa viene convertita nella codepage predefinita del database . Questo può non riconoscere determinati caratteri.

+0

Non risponde alla domanda. Non stavo chiedendo perché è lì. Mi stavo chiedendo se c'è un lato negativo o se è una buona pratica averlo lì a prescindere. – jcollum

+0

No, non lo sarebbe, se non è necessario ... –

Problemi correlati