TL; DR
Non esiste una visione "collettiva" dei fornitori, né una "versione indipendente", poiché le loro implementazioni - compresi quali aspetti possono essere resi insensibili e le convenzioni di denominazione - sono specifiche del fornitore e cambiano nel tempo .
Ecco un riepilogo di ciò che ho trovato, e i dettagli sono nella sezione più lunga sotto la riga:
RDBMS Naming- Combinations Case-Sensitive and
convention of options? Accent-Insensitive support?
------- ------------ ------------- -----
SQL Server _CS, _AI, etc Yes Latin1_General_100_CS_AI
DB2 _E{x}, _S{y}, etc Yes CLDR181_EO_S1
PostgreSQL locale: en_US N/A unaccent(), not via Collation
MySQL _cs, maybe _ai No No: _cs implies _as & _ci implies _ai
Yes? Create your own Collation :-)
Oracle only _CI & _AI No No: _AI always implies _CI
SAP ASE arbitrary: turdict N/A No: "AI" always implies "CI"
Informix locale.codepage N/A No: no "AI" via Collations
Come puoi vedere nel grafico, due dei sette RDBMS supportano nativamente le operazioni "sensibili al maiuscolo / minuscolo e sensibile agli accenti" tramite le regole di confronto, sebbene abbiano convenzioni di denominazione diverse (e diverse altre differenze funzionali).
Un RDBMS - PostgreSQL - non supporta nativamente questa combinazione, ma puoi comunque raggiungerlo togliendo gli accenti con la funzione unaccent()aggiuntiva.
Gli ultimi quattro RDBMS, due dei quali hanno una convenzione di denominazione simile per le opzioni, non supportano nativamente questa combinazione né sembra esserci un modo per raggiungere questo obiettivo senza scrivere la propria funzione per rimuovere gli accenti / segni diacritici. MySQL consente di creare le proprie regole di confronto, ma ciò richiede che sia necessario aggiungerlo al controllo del codice sorgente e incorporarlo nel processo di test e distribuzione in modo che possa essere applicato a tutti i server in tutti gli ambienti (ma è comunque un'opzione molto interessante e flessibile) . SAP ASE afferma che SAP può fornire ulteriori ordini di ordinamento Unicode, ma nessuna menzione di ciò che potrebbero essere disposti a fornire.
Per quanto riguarda:
C'è una buona ragione per questo o il mio è solo un raro caso d'uso?
Posso dire che nel fare la ricerca di questa risposta mi sono imbattuto in molti casi di persone che non volevano distinguere tra maiuscole e minuscole per MySQL, ma pochi, se non nessuno, chiedevano la combinazione desiderata.
Volevo che una condizione di ricerca utilizzasse un confronto maiuscole / minuscole ma non sensibile all'accento, ma non sono riuscito a trovarne una.
...
questa domanda è indipendente dal fornitore / versione
Non hai avuto successo nella tua ricerca perché non ha davvero senso cercare un RDBMS basato su una specifica Collation. Non è così che funzionano le collazioni. E mentre vuoi avvicinarti a questo come indipendente dal fornitore, la realtà è che le collazioni - almeno la parte con cui interagiamo - sono molto specifiche del fornitore e non si adattano sempre allo schema che stavi cercando .
Il confronto e l'ordinamento delle stringhe sono estremamente complessi e ci sono diversi modi per eseguire queste regole. Un metodo consiste nell'avere mappature che tengono conto di una o più regole. Quindi le quattro combinazioni di Sensibile e Insensibile per Case e Accenti equivarrebbero a quattro mappature separate. Ad esempio, è stato visualizzato nella pagina MSDN per il nome del confronto di SQL Server . Se scorri verso il basso, vedrai che la colonna di sinistra del grafico è la Sort Order ID. Ogni confronto ha un ID diverso: SQL_Latin1_General_Cp1_CI_AS= 52 while SQL_Latin1_General_Cp1_CS_AS= 51, anche se l'unica differenza è nella distinzione tra maiuscole e minuscole.
In alternativa, può essere basato su regole, ad esempio ciò che Unicode offre tramite Unicode Collation Algorithm (UCA). In questo approccio, a ogni personaggio viene assegnato, di default, uno o più pesi. Quindi, ogni cultura / locale ha la possibilità di sovrascrivere uno di quei pesi, o rimuovere regole o aggiungere regole. L'algoritmo tiene conto di eventuali regole specifiche della locale e quindi potenzialmente manipola quei pesi in base alle opzioni scelte (sensibilità, il caso viene prima quando si eseguono ordinamenti sensibili al maiuscolo / minuscolo, ecc.). Questo è uno dei motivi per cui l'ordinamento Unicode è un po 'più lento dell'ordinamento non Unicode.
Per avere un'idea di quante opzioni ci sono davvero (ovvero la complessità effettiva), dai un'occhiata a questa demo dal progetto ICU (International Components for Unicode):
Demo di confronto ICU
Ci sono 8 opzioni separate per specificare, e alcuni di loro vengono rappresentati in più elementi del disciplinare nome di confronto che si sta pensando di (ad esempio CS, CI, AS, AI, ecc). Considerando quante variazioni ci sono, usando l'approccio del file di mappatura in cui ogni combinazione ha il proprio ID si tradurrebbe in molte migliaia di file. Molti di questi file dovrebbero essere aggiornati ogni volta che ci sono cambiamenti in quelle particolari lingue o quando vengono rilevati dei bug. Questo è probabilmente il motivo per cui ci sono solo 75 di questi tipi di regole di confronto in SQL Server 2012 (ovvero quelli con nomi che iniziano con SQL_). Quindi nessuna combinazione per _CS_AI.
E il motivo per cui non sei riuscito a trovare quella combinazione per le collazioni basate sull'UCA? Bene, ci sono 3810 regole di confronto in SQL Server 2012 che non iniziano SQL_, quindi 3885 regole di confronto in totale. Tale elenco sembra essere troppo lungo per essere elencato completamente in una pagina Web. Ma questo non spiega completamente perché non sei riuscito a trovare questa combinazione per altri fornitori.
Oltre a ciò che è già stato menzionato (ovvero troppe combinazioni da implementare e troppe implementazioni da elencare), è ancora necessario fare i conti con implementazioni specifiche del fornitore. Significato: non tutti i fornitori consentono di adattare tutte queste opzioni e in primo luogo non esiste una convenzione di denominazione standard per le regole di confronto. Inoltre, non tutti i fornitori visualizzano le opzioni di ordinamento come parte delle regole di confronto: le regole di confronto PostgreSQL sono ordinazioni predefinite per la locale prescelta ed è necessario utilizzare ILIKEper ottenere un confronto senza distinzione tra maiuscole e minuscole. Vedi sotto per informazioni specifiche del fornitore.
SQL Server (Microsoft)
La distinzione tra ciò che vedi in quelle due pagine di documentazione MSDN e la query fornita da @MartinSmith in un commento sulla domanda (leggermente rivisto di seguito):
SELECT *
FROM sys.fn_helpcollations()
WHERE [name] LIKE '%[_]CS[_]AI%';
è che quelle due pagine MSDN si riferiscono in modo specifico alle regole di confronto di SQL Server molto deprecate, mentre le regole di confronto visualizzate come risultato di quella query (888 di esse a partire da SQL Server 2012, SP3) sono regole di confronto di Windows.
A partire da SQL Server 2000, le precedenti regole di confronto di SQL Server (create prima che SQL Server potesse accedere alle regole di confronto di Windows) sono obsolete e non vengono aggiornate con nuove regole o funzionalità. Ad esempio, a partire da SQL Server 2012, è stato aggiunto un set di regole di confronto che supportano la corretta gestione delle funzioni integrate per i caratteri supplementari (ovvero i caratteri UTF-16 rimanenti oltre i 65.536 caratteri "base" inizialmente definiti in UCS-2 ). Queste nuove collazioni terminano in _SC(come nei caratteri S in C supplementari ).
È meglio non utilizzare le regole di confronto di SQL Server, ovvero quelle con nomi che iniziano con SQL_. Quindi hai accesso a molte Collation che supportano la combinazione di opzioni che stai cercando (cioè maiuscole e minuscole). Ogni volta che è disponibile, è anche meglio usare un'estremità _SCpurché abbia tutte le altre opzioni che desideri.
Mentre SQL Server utilizza la _CS_AIconvenzione di denominazione, non esiste un elenco di tutte le regole di confronto 3810 (a partire da SQL Server 2012). C'è solo la pagina Nome regole di confronto di Windows che elenca tutte le versioni locali e le versioni e come funziona la convenzione di denominazione, ma il gioco è fatto.
SQL Server supporta anche l'attivazione / disattivazione della sensibilità di Larghezza e Kana.
MySQL (acquistato da Oracle)
La versione di MySQL 5.7, documentazione afferma che non supporta il _ai, _as, _ci, e _cssuffissi (e _binper completezza), ma afferma anche:
Per i nomi delle regole di confronto non binari che non specificano la sensibilità dell'accento, viene determinato dalla maiuscola / minuscola. Cioè, se il nome di una collation non contiene _aio _as, _cinel nome implica _aie _csnel nome implica _as.
Ad esempio, latin1_general_cifa distinzione tra maiuscole e minuscole (e accento insensibile, implicitamente), latin1_general_csfa distinzione tra maiuscole e minuscole (e accento, implicitamente)
Ciò implica certamente che è possibile avere una latin1_general_cs_aicollazione. Tuttavia, il server MySQL 5.5.50 che ho accesso a non ha regole di confronto con più di un suffisso, e il suffisso solo io vedo sono: _cs, _ci, e _binattraverso regole di confronto 198 totali. Ho usato il comando SHOW COLLATION per elencarli.
Quindi, mentre sembra che MySQL utilizzi una convenzione di denominazione simile (almeno per quanto riguarda queste due opzioni), non riesco a trovare una collazione che corrisponda a ciò che stai cercando. Tuttavia, potrebbe essere possibile rimuovere gli accenti (e altri segni diacritici) e utilizzare una _csraccolta per ottenere ciò che desideri (simile a come lo faresti in PostgreSQL - vedi sotto). Ma non sono sicuro di questa opzione e al momento non ho tempo per ulteriori ricerche.
OPPURE , potresti creare la tua raccolta personale per fare esattamente quello che vuoi. A differenza degli altri RDBMS, MySQL sembra rendere piuttosto semplice aggiungere le proprie regole di confronto, nel qual caso hai il pieno controllo sulla ponderazione di ciascun personaggio. Per ulteriori dettagli, vedere Aggiunta di un confronto semplice a un set di caratteri a 8 bit e Aggiunta di un confronto UCA a un set di caratteri Unicode .
Per ulteriori informazioni su come MySQL gestisce diversi tipi di regole di confronto, consulta la pagina Tipi di implementazione delle regole di confronto .
PostgreSQL
Le regole di confronto in PostgreSQL sembrano essere molto meno flessibili. Si specifica solo la cultura / locale: en_US, de_DE, ecc Si prega di vedere la loro pagina di documentazione per la fascicolazione di sostegno per i dettagli. Quindi, per impostazione predefinita si ottengono le sostituzioni specifiche della cultura, ma le regole di confronto sono altrimenti sensibili a tutto (che, a proposito, non è la stessa di una raccolta "binaria").
È possibile utilizzare ILIKE (sezione 9.7.1) per ottenere insensibilità al maiuscolo / minuscolo, ma non hanno un operatore simile per la sensibilità all'accento. Tuttavia, ho scoperto che hanno una funzione non accente che può essere utilizzata per rimuovere accenti e altri segni diacritici. Si noti che questa funzione è un modulo aggiuntivo fornito e quindi non è necessariamente presente in alcun particolare server PostgreSQL da utilizzare. Che la documentazione collegata più recentemente afferma:
Quando si crea dalla distribuzione di origine, questi componenti non vengono creati automaticamente, a meno che non si crei il target "world"
...
Se si utilizza una versione preconfezionata di PostgreSQL, questi moduli sono in genere resi disponibili come un pacchetto secondario separato, come postgresql-contrib.
Consulta la documentazione per istruzioni su come ottenere quella funzione se non la possiedi e la desideri.
Ulteriori informazioni sono inoltre disponibili nella seguente risposta Stack Overflow:
PostgreSQL supporta regole di confronto "insensibili all'accento"?
DB2 (IBM)
Simile a Microsoft SQL Server, DB2 ha due tipi di regole di confronto:
Regole di confronto "SISTEMA", che vengono specificati utilizzando il seguente formato: SYSTEM_{codepage}_[optional-territory]. Questi non sono molto flessibili e non sembrano supportare la sensibilità di adattamento a caso, accenti o altro. Puoi trovare l'elenco delle regole di confronto supportate qui: Codici di territorio e pagine codici supportati
Collazioni basate su algoritmo di confronto Unicode (UCA). Questi supportano un bel po 'di sartoria. Per i dettagli su come configurare il comportamento, la convenzione di denominazione e l'elenco di impostazioni locali valide, consultare la pagina delle regole di confronto basata sull'algoritmo di confronto Unicode . Si noti che nella Tabella 1, l'esempio nella terza riga ("Livello case") inizia con:
Impostando l'attributo Livello case su on e l'attributo Forza su livello primario ignorerà l'accento ma non il caso.
Questo è esattamente quello che stavi cercando. Ma, la sintassi per che è:
CLDR181_EO_S1. Ed è per questo che la tua ricerca non ha trovato nulla relativo a DB2.
Oracolo
Oracle 10g ha aggiunto il supporto per eseguire confronti e ordinamenti insensibili agli accenti. Tuttavia:
- hanno solo le opzioni per indicare operazioni "insensibili":
_CIe_AI
- puoi specificare solo una di queste opzioni alla volta
- l'opzione senza distinzione tra maiuscole e minuscole -
_CI- è ancora sensibile all'accento
- l'opzione insensibile all'accento -
_AI- "è sempre insensibile anche alle maiuscole". (citato dalla loro documentazione che è collegata di seguito)
Per ulteriori dettagli ed esempi, consultare la relativa documentazione relativa all'ordinamento linguistico e alla ricerca di stringhe .
SAP ASE (precedentemente Sybase ASE, aka Sybase)
ASE supporta una o più delle seguenti combinazioni di sensibilità per ogni locale / set di caratteri:
- sensibile al maiuscolo / minuscolo, sensibile all'accento
- senza distinzione tra maiuscole e minuscole, sensibile all'accento
- senza distinzione tra maiuscole e minuscole, sensibile all'accento, ordina con preferenza
- senza distinzione tra maiuscole e minuscole, non sensibile all'accento
È possibile visualizzare la relazione tra impostazioni internazionali, set di caratteri e ordinamenti disponibili nella pagina Selezione dell'ordinamento predefinito . E puoi vedere l'elenco completo delle regole di confronto nella pagina Nomi e ID delle regole di confronto .
La loro convenzione di denominazione delle regole di confronto è arbitraria in quanto sono tutti 4 - 8 caratteri e cercano di acquisire il nome della locale o la tabella codici e un certo senso dell'ordinamento. Per esempio:
altnoacc== "Alternativa CP 850 - nessun accento"
rusdict== "Ordinamento dizionario russo"
dynix== "Ordinamento fonetico cinese"
C'è una nota nella pagina Selezione dell'ordinamento Unicode predefinito che afferma:
È possibile aggiungere ordini di ordinamento utilizzando file esterni nella $/collate/Unicodedirectory. I nomi e gli ID di confronto sono memorizzati in syscharsets. Non è necessario che siano presenti i nomi degli ordinamenti Unicode esterni syscharsetsprima di poter impostare l'ordinamento Unicode predefinito.
...
Gli ordinamenti Unicode esterni sono forniti da SAP. Non tentare di creare ordinamenti Unicode esterni.
Non è chiaro se SAP fornirebbe un ordinamento esterno per consentire la distinzione tra maiuscole e minuscole e sensibile agli accenti. Forse un giorno li invierò per email e chiederò se uno potrebbe essere richiesto.
Per ottenere la combinazione desiderata di sensibilità, dovresti essere in grado di creare una funzione scalare definita dall'utente per eliminare gli accenti e altri segni diacritici.
Informix (acquistato da IBM)
Informix sembra supportare principalmente l'ordinamento predefinito e il comportamento di confronto di un confronto. Quindi le regole di confronto sono solo le impostazioni internazionali e il set di caratteri. La distinzione tra maiuscole e minuscole viene gestita a livello di database e, per impostazione predefinita, distingue tra maiuscole e minuscole. È possibile impostare un database (non un tavolo, o di una colonna, o di una query, o anche un predicato) di essere case-insensitive da specificando NLSCASE INSENSITIVE nella CREATE DATABASEdichiarazione.
Sebbene le regole di confronto del database - impostazioni internazionali e set di caratteri - possano essere sovrascritte per connessione client, non sembra esserci un modo per ignorare l'impostazione della distinzione tra maiuscole e minuscole. E, l' NLSCASEopzione ha "NLS" nel nome per un motivo: riguarda solo dati NCHARe NVARCHARdati; CHARe VARCHARsono sempre sensibili al maiuscolo / minuscolo.
La sensibilità agli accenti non viene affrontata, né esiste una funzione integrata per eliminare gli accenti / segni diacritici.
La convenzione di denominazione di Informix Collation è:
<lang>_<country>.<code set>
dove:
<lang> = un codice lingua di 2 o 3 lettere<country> = un codice paese o regione di 2 lettere<code set> = la tabella codici specificata in uno dei 3 seguenti modi equivalenti:
- nome: 8859-1
- valore decimale del numero IBM CCSID: 819
- valore esadecimale del numero CCSID IBM: 0333
Pertanto, le seguenti tre specifiche locali si riferiscono esattamente alla stessa locale:
- fr_fr.8859-1
- fr_fr.819
- fr_fr.0333
Per ulteriori informazioni, consultare: