2009-04-21 18 views
10

Attualmente sto memorizzando versioni normalizzate di stringhe nel mio database SQL Server in minuscolo. Ad esempio, nella mia tabella Utenti, ho un campo UserName e LoweredUserName. A seconda del contesto, uso la funzione LOWER() di T-SQL o il metodo String.ToLower() di C# per generare la versione minuscola del nome utente per riempire il campo LoweredUserName. Secondo Microsoft's guidelines e Visual Studio's code analysis rule CA1308, dovrei usare C#. String.ToUpperInvariant() invece di ToLower(). Secondo Microsoft, si tratta di un problema di prestazioni e di globalizzazione: la conversione in maiuscolo è sicura, mentre la conversione in minuscolo può causare una perdita di informazioni (ad esempio, the Turkish 'I' problem).Normalizzazione delle stringhe con String.ToUpperInvariant()

Se passo a utilizzare ToUpperInvariant per la normalizzazione delle stringhe, dovrò cambiare anche lo schema del mio database, poiché il mio schema si basa sul framework Microsoft's ASP.NET Membership (vedi this related question), che normalizza le stringhe in minuscolo.

Microsoft non contraddice se stesso dicendoci di utilizzare la normalizzazione maiuscola in C#, mentre il proprio codice nelle tabelle Membership e le procedure utilizzano la normalizzazione in minuscolo? Devo passare tutto alla normalizzazione delle maiuscole o continuare semplicemente usando la normalizzazione in minuscolo?

risposta

3

Per rispondere alla prima domanda, sì, Microsoft è un po 'incoerente. Per rispondere alla seconda domanda, non passare nulla finché non si è verificato che ciò sta causando un collo di bottiglia nell'applicazione.

Pensa a quanti progressi puoi realizzare sul tuo progetto invece di perdere tempo a cambiare tutto. Il tuo tempo di sviluppo è molto più prezioso dei risparmi che otterresti da un tale cambiamento.

Ricorda:

ottimizzazione prematura è la radice di tutti i mali (o almeno la maggior parte di esso) in programmazione. - Donald Knuth

+0

Questo non è solo un problema di prestazioni, è anche un problema di globalizzazione. Secondo Microsoft, la conversione in maiuscolo è sicura, mentre la conversione in minuscolo può causare una perdita di informazioni (ad esempio, nel problema turco "I"). –

+2

@Kevin, il problema I senza macchia turco/azero rimane un caso speciale a prescindere dall'approccio (sono maiuscoli i a İ e ı a I), sebbene il minuscolo sia ambiguo per SS (dovrebbe essere ss o ß) ma anche imperfetto (alcune ortografie sono ancora in maiuscolo ß in SZ). È ancora meglio però. Meglio ancora usare le regole di piegatura delle maiuscole Unicode con un interruttore Turkic per i e ı, ma non sarà ancora perfetto, che può essere solo per locale :( –

6

Secondo CA1308, la ragione per fare questo è che alcuni caratteri non possono essere convertiti andata e ritorno da maiuscole a lettere minuscole. L'importante è che ti muovi sempre in una direzione, quindi se il tuo standard è di passare sempre in minuscolo, non c'è motivo di cambiarlo.

+4

Mi piace questo approccio. Se si parte da zero, si segua la raccomandazione lo standard è sempre la migliore pratica alla luce di nessun'altra motivazione a fare diversamente, ma quando si lavora sulla manutenzione esistente, è spesso una follia semplicemente passare perché lo dice. È necessario dimostrare in modo convincente che il progetto trarrà vantaggio dal cambiamento prima di intraprendere tale una revisione - forse quando inizi a processare il turco e hai un problema? –

+0

Sono assolutamente d'accordo, Jeff, ci sono alcune linee guida che dovresti seguire e direi che potrebbe valere la pena di aggiornare il codice esistente da seguire (assicurandoti di disporre il tuo lettore di dati per esempio), ma questa non è una di quelle regole, né è neanche lontanamente simile. – JoshBerke

-2

Continuare a utilizzare la normalizzazione in minuscolo. Cambiare solo per conformarsi agli standard Microsoft se si sviluppa un grosso problema.

Questo è un peccato, ma ne vale la pena. Purtroppo, gli "standard" di Microsoft tendono ad essere scarsamente considerati e alquanto meno consistenti; l'esperienza con loro ha dimostrato che, a meno che non vi sia una ragione convincente, è meglio attenersi semplicemente a ciò che funziona mentre funziona. Si noti che questo in genere NON è vero per le tecnologie non Microsoft; ma l'arbitrarietà degli "standard" di Microsoft li rende degni di essere evitati.

Modifica: dovrei chiarire qui; la mia opinione su Microsoft è molto bassa, da una lunga esperienza con i loro standard. Come è stato sottolineato nei commenti, non ho riferimenti particolari per indicare "tutti gli altri tranne Microsoft"; questo viene solo dalla mia esperienza personale. Il tuo chilometraggio può variare ampiamente. Questa risposta dovrebbe essere considerata davvero solo la mia opinione. Scusa per non averlo chiarito prima.

+5

Penso che sia necessario citare alcune fonti prima di fare affermazioni su "tutti tranne Mi crosoft "quando si tratta di standard. Negli ultimi anni, Microsoft sembra aver fatto molta attenzione nella ricerca delle motivazioni dietro i loro standard e mentre la loro implementazione degli standard web in IE è stata tutt'altro che ideale, gli standard che definiscono per noi lavorare all'interno dei loro prodotti sono spesso eccellenti. Per favore, fai il backup delle tue affermazioni, perché non vengano interpretate come opinioni amare. –

+3

Sono d'accordo con Jeff, i loro standard sono molto coerenti, la loro adozione dei loro standard è inferiore ma questo è previsto, il codice che è stato scritto prima di uno standard adottato non verrà aggiornato solo per portarlo in aderenza, Immagina se cambiassero tutto i loro spazi nome per riflettere il loro nuovo approccio per la raccolta di spazi dei nomi e tutti gli sviluppatori che avrebbero gridato il sanguinoso omicidio. – JoshBerke

+0

I tuoi punti sono entrambi buoni; La mia posizione infatti deriva da opinioni piuttosto aspre e tanta tanta esperienza con Microsoft. Aggiornerò per riflettere questo –