Best practice per il mantenimento di lettere maiuscole e dati del caso corretto

Suggerirei di non forzare le stringhe inserite dall'utente in alcun formato "corretto", eccetto per il taglio degli spazi iniziali e finali. Nel caso del trasferimento dei dati, lasciatelo nel formato esistente, ma memorizza i nuovi dati appena inseriti.

Se è necessario un caso "corretto" ai fini della prestazione, puoi costringere sia i dati che i criteri in un caso arbitrario. Sarebbe meglio indicizzare su una funzione caso arbitraria applicata ai dati (o creare una colonna caso arbitrario duplicata se il database non supporta quel tipo di indice) e i criteri di coercizione in quel caso.

Per le stringhe, penso che la migliore pratica sia quella di fidarsi che l'utente significhi ciò che dicono, perché ogni supposizione che si esegue sarà spesso sbagliata. L'eccezione sarebbe quando vengono date istruzioni per entrare in un particolare formato, in tal caso eseguire la formattazione per loro conto, ove possibile (es .: se entrano nel caso sbagliato, basta correggerlo piuttosto che generare un errore).

I nomi delle persone non sono maiuscole utilizzando le regole del caso appropriate. Nel tuo esempio, la corretta maiuscola di O'neil è O'Neil. A seconda dell'individuo, l'errata maiuscola del proprio nome potrebbe essere alquanto offensiva. Non ha senso correre il rischio di offendere un potenziale cliente o (peggio!) Un cliente esistente sfruttando erroneamente il proprio nome in stampa e le comunicazioni elettroniche con loro.

Questo problema è interamente un problema di ciò di cui hanno bisogno i consumatori . Non è un problema di programmazione in quanto entrambi possono essere raggiunti (anche se il propercasing è più difficile). In azienda lavoro per gli utenti non voglio mai vedere tutto in maiuscolo e quindi propercase tutto in fase di importazione. Volevano tutto in maiuscolo, lo faremmo.

Potresti avere una regola aziendale che aumenta il carattere a destra di "o che fa scalare il chareter a destra di Mac o Mc (quando appaiono all'inizio del nome). Sarebbe anche uppcase II, IV o III quando sono alla fine di un nome. Che gestisce la maggior parte dei problemi di nome della gente.

Se trovi le eccezioni che desideri man mano, puoi creare una tabella delle eccezioni con la versione del nome proposta. Puoi usare quella correzione per qualsiasi nome che venga all'attenzione dell'azienda che non fa parte delle normali regole. Questo alla fine includerà quasi tutti i problemi di nome che hai.

I nomi e gli indirizzi delle società sono più difficili e accettiamo qualsiasi cosa la normale funzione di propercasing distribuisca per le importazioni e tutto ciò che è digitato per i record aggiunti dalla GUI. Se qualcuno si attiene alla maiuscola, possiamo risolverlo tramite la GUI e l'importazione non lo aggiornerà.

Un argomento per tutti i dati maiuscoli è che è il più suscettibile all'internazionalizzazione di tutti i formati. Ecco perché Microsoft consiglia il uppercasing anziché il minuscolo nel framework .NET :

Use the String.ToUpperInvariant method instead of the String.ToLowerInvariant method when you normalize strings for comparison.

Questo potrebbe non avere importanza per il tuo caso.

Ci sono anche alcuni benefici secondari, per esempio, le lettere maiuscole tendono ad essere più facili da leggere per quelle con visione non ideale.

Nel complesso, non posso pensare a un gran numero di considerazioni. I nomi dei nomi sono solo nomi, il loro involucro di solito non cambia il contesto a meno che tu non stia applicando i nomi in un contesto piuttosto che avere solo il nome per scopi di reporting o di tipo statistico. Quindi se stai creando messaggi di benvenuto o qualcosa del genere, il caso è probabilmente molto più importante.