TL; DR
Tidak ada yang namanya pandangan "vendor-agnostik" terhadap Collations, atau bahkan "versi-agnostik", karena implementasinya - termasuk aspek mana yang dapat dibuat tidak peka dan konvensi penamaannya - bersifat spesifik vendor dan berubah seiring waktu .
Berikut adalah ringkasan dari apa yang saya temukan, dan detailnya ada di bagian yang lebih panjang di bawah garis:
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
Seperti yang dapat Anda lihat dalam bagan, dua dari tujuh RDBMS secara asli mendukung operasi " Peka-huruf dan tidak-sensitif" melalui Collations, meskipun mereka memiliki konvensi penamaan yang berbeda (dan beberapa perbedaan fungsional lainnya).
Satu RDBMS - PostgreSQL - tidak mendukung kombinasi ini secara native, tetapi Anda masih dapat mencapainya dengan menghilangkan aksen dengan fungsi unaccent()add-on.
Empat RDBMS terakhir, dua di antaranya memiliki konvensi penamaan yang serupa untuk opsi, tidak secara alami mendukung kombinasi ini atau tampaknya tidak ada cara untuk mencapai ini tanpa menulis fungsi Anda sendiri untuk menghilangkan aksen / tanda diakritik. MySQL memungkinkan untuk membuat Collations Anda sendiri, tetapi itu mengharuskan Anda kemudian menambahkannya ke kontrol sumber dan memasukkannya ke dalam proses pengujian & penempatan Anda sehingga dapat diterapkan ke semua server di semua lingkungan (tetapi masih merupakan opsi yang sangat keren dan fleksibel) . SAP ASE menyebutkan bahwa SAP dapat menyediakan pesanan semacam Unicode tambahan, tetapi tidak menyebutkan apa yang mungkin bersedia mereka berikan.
Berkaitan dengan:
Apakah ada alasan bagus untuk ini atau hanya milik saya yang jarang digunakan?
Saya dapat mengatakan bahwa dalam melakukan penelitian untuk jawaban ini saya menemukan banyak contoh orang yang ingin case-insensitive dan peka-aksen untuk MySQL, tetapi sedikit, jika ada, meminta kombinasi yang Anda inginkan.
Saya ingin kondisi pencarian menggunakan collation case-sensitive tapi accent-sensitive tetapi tidak bisa menemukannya.
...
pertanyaan ini adalah vendor / versi agnostik
Anda tidak berhasil dalam pencarian Anda karena itu tidak masuk akal untuk mencari RDBMS berdasarkan spesifikasi Collation. Itu bukan cara kerja Collations. Dan sementara Anda ingin mendekati ini sebagai agnostik vendor, kenyataannya adalah bahwa Collations - setidaknya bagian yang kami berinteraksi dengan - sangat spesifik untuk vendor, dan tidak selalu cocok dengan skema yang Anda cari. .
Perbandingan dan penyortiran string sangat kompleks, dan ada berbagai cara untuk melakukan aturan ini. Salah satu metode adalah memiliki pemetaan yang memperhitungkan satu aturan atau lebih. Oleh karena itu empat kombinasi Sensitive dan Insensitive untuk Case dan Accents akan sama dengan empat pemetaan terpisah. Misalnya, Anda melihat ini di halaman MSDN untuk Nama Kolasi SQL Server . Jika Anda menggulir ke bawah, Anda akan melihat bahwa kolom kiri bagan adalah Sort Order ID. Setiap Collation memiliki ID yang berbeda: SQL_Latin1_General_Cp1_CI_AS= 52 sementara SQL_Latin1_General_Cp1_CS_AS= 51, meskipun satu-satunya perbedaan adalah dalam sensitivitas huruf.
Atau, itu bisa berbasis aturan, seperti apa yang ditawarkan Unicode melalui Unicode Collation Algorithm (UCA). Dalam pendekatan ini, setiap karakter diberikan, secara default, satu atau lebih bobot. Kemudian, masing-masing budaya / lokal memiliki opsi untuk menimpa salah satu dari bobot itu, atau menghapus aturan, atau menambahkan aturan. Algoritma memperhitungkan setiap aturan spesifik lokal, dan kemudian berpotensi memanipulasi bobot tersebut berdasarkan opsi apa pun yang dipilih (sensitivitas, kasus mana yang didahulukan saat melakukan jenis huruf sensitif, dll). Ini adalah salah satu alasan mengapa melakukan penyortiran Unicode sedikit lebih lambat daripada penyortiran non-Unicode.
Untuk mengetahui berapa banyak opsi yang ada (yaitu kompleksitas aktual), lihat demo ini dari proyek ICU (International Components for Unicode):
Demo Pengumpulan ICU
Ada 8 pilihan yang terpisah untuk menentukan, dan beberapa dari mereka terwakili dalam beberapa elemen dari nama spesifikasi Fisik yang Anda berpikir untuk (misalnya CS, CI, AS, AI, dll). Mengingat banyaknya variasi yang ada, menggunakan pendekatan file pemetaan di mana setiap kombinasi memiliki ID sendiri akan menghasilkan ribuan file. Banyak dari file-file itu perlu diperbarui setiap kali ada perubahan dalam bahasa-bahasa tertentu, atau ketika bug ditemukan. Ini mungkin mengapa hanya ada 75 dari jenis Collations di SQL Server 2012 (yaitu yang dengan nama dimulai dengan SQL_). Karenanya tidak ada kombinasi untuk _CS_AI.
Dan alasan mengapa Anda tidak dapat menemukan kombinasi itu untuk Collations berbasis UCA? Ada 3810 Collations di SQL Server 2012 yang tidak dimulai SQL_, jadi total 3885 Collations. Daftar itu tampaknya terlalu panjang untuk disebutkan secara penuh pada halaman web. Tetapi ini tidak sepenuhnya menjelaskan mengapa Anda tidak dapat menemukan kombinasi ini untuk vendor lain.
Di luar apa yang telah disebutkan (yaitu terlalu banyak kombinasi untuk diterapkan, dan terlalu banyak implementasi untuk dicantumkan), Anda masih perlu bersaing dengan implementasi khusus vendor. Artinya: tidak semua vendor memungkinkan untuk menyesuaikan semua opsi tersebut, dan tidak ada konvensi penamaan standar untuk Collations. Juga, tidak semua vendor melihat opsi penyortiran sebagai bagian dari Collation: PostgreSQL Collations adalah pemesanan default untuk lokal yang dipilih, dan Anda perlu menggunakan ILIKEuntuk mendapatkan perbandingan case-insensitive. Lihat di bawah untuk info khusus vendor.
SQL Server (Microsoft)
Perbedaan antara apa yang Anda lihat di dua halaman dokumentasi MSDN dan permintaan yang diberikan oleh @MartinSmith dalam komentar pada pertanyaan (sedikit direvisi di bawah):
SELECT *
FROM sys.fn_helpcollations()
WHERE [name] LIKE '%[_]CS[_]AI%';
adalah bahwa kedua halaman MSDN merujuk secara khusus ke SQL Server Collations yang sangat usang, sedangkan collations yang muncul sebagai hasil dari permintaan itu (888 di antaranya dari SQL Server 2012, SP3) adalah Windows Collations.
Mulai di SQL Server 2000, SQL Server Collations yang lebih lama (dibuat sebelum SQL Server dapat memanfaatkan Windows Collations) sudah usang dan tidak diperbarui dengan aturan atau fungsi baru. Sebagai contoh, dimulai pada SQL Server 2012, satu set Collations ditambahkan yang mendukung penanganan yang tepat dari fungsi-fungsi bawaan untuk Karakter Tambahan (yaitu karakter UTF-16 yang tersisa di luar "basis" 65.536 karakter yang awalnya didefinisikan dalam UCS-2 ). Ini Collations baru berakhir pada _SC(seperti dalam S upplementary C haracters).
Yang terbaik adalah tidak menggunakan SQL Server Collations - yang dengan nama dimulai dengan SQL_. Karenanya Anda memiliki akses ke banyak Collations yang mendukung kombinasi opsi yang Anda cari (yaitu Case-Sensitive dan Accent-Insensitive). Kapan pun tersedia, yang terbaik adalah menggunakan salah satu ujungnya _SCselama ia memiliki semua opsi lain yang Anda inginkan.
Sementara SQL Server tidak menggunakan _CS_AIkonvensi penamaan, tidak ada daftar semua 3810 (pada SQL Server 2012) Windows Collations. Hanya ada halaman Windows Collation Name yang mencantumkan semua lokal dan versi, dan bagaimana konvensi penamaan bekerja, tetapi hanya itu.
SQL Server juga mendukung toggling sensitivitas Lebar dan Kana.
MySQL (dibeli oleh Oracle)
MySQL versi 5.7, dokumentasi menyatakan bahwa itu mendukung _ai, _as, _ci, dan _csakhiran (dan _binuntuk kelengkapan), tetapi juga menyatakan:
Untuk nama pemeriksaan non-biner yang tidak menentukan sensitivitas aksen, ditentukan oleh sensitivitas case. Yaitu, jika nama collation tidak mengandung _aiatau _as, _cidalam nama itu menyiratkan _aidan _csdalam nama menyiratkan _as.
Sebagai contoh, latin1_general_ciapakah case sensitive (dan accent insensitive, implisit), latin1_general_cscase sensitif (dan accent sensitive, implisit)
Ini tentu menyiratkan bahwa dimungkinkan untuk memiliki latin1_general_cs_aiCollation. Namun, MySQL 5.5.50 server yang saya memiliki akses ke tidak memiliki collations dengan lebih dari satu akhiran, dan satu-satunya akhiran saya lihat adalah: _cs, _ci, dan _bindi 198 Total Collations. Saya menggunakan perintah SHOW COLLATION untuk mendaftar mereka.
Jadi, walaupun kedengarannya seperti MySQL menggunakan konvensi penamaan yang serupa (setidaknya sejauh dua pilihan itu), saya tidak dapat menemukan Collation yang cocok dengan yang Anda cari. Namun, dimungkinkan untuk menghapus aksen (dan tanda diakritik lainnya) dan menggunakan _cssusunan untuk mendapatkan apa yang Anda inginkan (mirip dengan bagaimana Anda melakukannya di PostgreSQL - lihat di bawah). Tetapi saya tidak yakin dengan opsi ini dan tidak punya waktu saat ini untuk meneliti lebih lanjut.
ATAU , Anda dapat membuat Collation sendiri untuk melakukan apa yang Anda inginkan. Tidak seperti RDBMS lainnya, MySQL tampaknya membuatnya lebih mudah untuk menambahkan Collations Anda sendiri, dalam hal ini Anda memegang kendali penuh atas bobot masing-masing karakter. Silakan lihat Menambahkan Collation Sederhana ke Set Karakter 8-Bit dan Menambahkan Collation UCA ke Set Karakter Unicode untuk detail lebih lanjut.
Untuk info lebih lanjut tentang bagaimana MySQL menangani berbagai jenis Collations, silakan lihat halaman Jenis Implementasi Collation mereka .
PostgreSQL
Koleksi dalam PostgreSQL tampaknya jauh kurang fleksibel. Anda hanya menentukan budaya / lokal: en_US, de_DE, dll Silakan lihat halaman dokumentasi mereka untuk Fisik Dukungan untuk rincian. Oleh karena itu, secara default Anda mendapatkan penggantian budaya khusus, tetapi Collations sebaliknya semuanya sensitif (yang, omong-omong, tidak sama dengan pemeriksaan "biner").
Anda dapat menggunakan ILIKE (bagian 9.7.1) untuk mendapatkan ketidakpekaan huruf besar-kecil, tetapi mereka tidak memiliki operator yang serupa untuk sensitivitas aksen. Namun, saya menemukan bahwa mereka memiliki fungsi yang tidak mencolok yang dapat digunakan untuk menghilangkan aksen dan tanda diakritik lainnya. Harap dicatat bahwa fungsi ini adalah Modul Tambahan yang Disediakan dan karenanya tidak perlu hadir dalam server PostgreSQL tertentu untuk digunakan. Dokumentasi tertaut yang terbaru menyatakan:
Ketika membangun dari distribusi sumber, komponen-komponen ini tidak dibangun secara otomatis, kecuali jika Anda membangun target "dunia"
...
Jika Anda menggunakan versi PostgreSQL pra-paket, modul-modul ini biasanya tersedia sebagai sub-paket terpisah, seperti postgresql-contrib.
Silakan lihat dokumentasi untuk instruksi tentang cara mendapatkan fungsi itu jika Anda tidak memilikinya dan menginginkannya.
Informasi lebih lanjut juga dapat ditemukan dalam jawaban Stack Overflow berikut:
Apakah PostgreSQL mendukung pemeriksaan “tidak sensitif aksen”?
DB2 (IBM)
Mirip dengan Microsoft SQL Server, DB2 memiliki dua jenis Collations:
"SYSTEM" Collations, yang dispesifikasikan menggunakan format berikut: SYSTEM_{codepage}_[optional-territory]. Ini tidak terlalu fleksibel, dan tampaknya tidak mendukung kepekaan menyesuaikan huruf besar-kecil, aksen, atau apa pun. Anda dapat menemukan daftar Collations yang didukung di sini: Kode wilayah yang didukung dan halaman kode
Algoritma Collation Unicode Collation (UCA). Ini memang mendukung sedikit penyesuaian. Silakan lihat halaman collation Algorithm Collation Algorithm mereka untuk perincian tentang cara mengkonfigurasi perilaku, konvensi penamaan, dan daftar lokal yang valid. Harap perhatikan bahwa pada Tabel 1, contoh di baris ketiga ("Level Kasus") dimulai dengan:
Mengatur atribut Level Case ke on dan atribut Strength ke level primer akan mengabaikan aksen tetapi tidak case.
Itulah tepatnya yang Anda cari. Tapi, sintaks untuk itu adalah:
CLDR181_EO_S1. Dan inilah mengapa pencarian Anda tidak menemukan apa pun yang terkait dengan DB2.
Peramal
Oracle 10g menambahkan dukungan untuk melakukan perbandingan dan penyortiran tidak peka aksen. Namun:
- mereka hanya memiliki opsi untuk menunjukkan operasi "tidak sensitif":
_CIdan_AI
- Anda hanya dapat menentukan salah satu opsi tersebut sekaligus
- opsi case-insensitive -
_CI- masih peka aksen
- opsi aksen-tidak sensitif -
_AI- "juga selalu case-insensitive." (dikutip dari dokumentasi mereka yang terhubung di bawah)
Silakan lihat halaman dokumentasi Penyortiran Linguistik dan Pencarian String untuk detail dan contoh lebih lanjut.
SAP ASE (sebelumnya Sybase ASE, alias Sybase)
ASE mendukung satu atau lebih kombinasi sensitivitas berikut ini per setiap rangkaian karakter / lokal:
- peka huruf besar-kecil, peka-aksen
- case-insensitive, peka-aksen
- case-insensitive, accent-sensitive, ketertiban dengan preferensi
- case-insensitive, accent-insensitive
Anda dapat melihat hubungan antara lokal, rangkaian karakter, dan urutan pemesanan yang tersedia di halaman Memilih Urutan Urutan Default . Dan Anda dapat melihat daftar lengkap dari Collations pada halaman Collation Names and IDs mereka .
Konvensi penamaan Collation mereka sewenang-wenang karena semuanya terdiri dari 4 - 8 karakter dan mencoba untuk menangkap nama lokal atau halaman kode dan dan beberapa pengertian penyortiran. Sebagai contoh:
altnoacc== "Alternatif CP 850 - tanpa aksen"
rusdict== "Pemesanan kamus Rusia"
dynix== "Pemesanan fonetik Cina"
Ada catatan pada halaman Memilih Memilih Urutan Kode Unicode Default yang menyatakan:
Anda dapat menambahkan perintah sortir menggunakan file eksternal di $/collate/Unicodedirektori. Nama dan ID kolasi disimpan di syscharsets. Nama perintah sortir Unicode eksternal tidak harus ada syscharsetssebelum Anda dapat mengatur urutan sortir Unicode default.
...
Pesanan penyortiran Unicode eksternal disediakan oleh SAP. Jangan mencoba membuat pesanan sortir Unicode eksternal.
Tidak jelas apakah SAP akan menyediakan pesanan penyortiran eksternal untuk memungkinkan Case-Sensitive dan Accent-Insensitive. Mungkin suatu hari saya akan mengirim email kepada mereka dan bertanya apakah ada yang bisa diminta.
Untuk mendapatkan kombinasi sensitivitas yang diinginkan, Anda harus dapat membuat fungsi skalar yang ditentukan pengguna untuk menghilangkan aksen dan tanda diakritik lainnya.
Informix (dibeli oleh IBM)
Informix tampaknya sebagian besar hanya mendukung penyortiran default dan perilaku perbandingan suatu Collation. Karenanya Collations hanyalah set lokal dan karakter. Sensitivitas huruf ditangani pada tingkat basis data, dan secara default peka huruf besar-kecil. Anda bisa mengatur database (bukan tabel, atau kolom, atau kueri, atau bahkan predikat) menjadi case-insensitive dengan menentukan NLSCASE INSENSITIVE dalam CREATE DATABASEpernyataan.
Sementara Database collation - set lokal dan karakter - dapat diganti per koneksi klien, tampaknya tidak ada cara untuk menimpa pengaturan sensitivitas kasus. DAN, NLSCASEopsi memiliki "NLS" dalam nama karena suatu alasan: hanya mempengaruhi NCHARdan NVARCHARdata; CHARdan VARCHARselalu case-sensitive.
Sensitivitas-aksen tidak dialamatkan, juga tidak ada fungsi bawaan untuk menghilangkan aksen / tanda diakritik.
Konvensi penamaan Informix Collation adalah:
<lang>_<country>.<code set>
dimana:
<lang> = kode bahasa 2 huruf atau 3 huruf<country> = kode negara atau wilayah 2 huruf<code set> = halaman kode yang ditentukan dalam salah satu dari 3 cara setara berikut:
- nama: 8859-1
- nilai desimal nomor IBM CCSID: 819
- nilai heksadesimal nomor IBM CCSID: 0333
Karenanya, tiga spesifikasi lokal berikut semuanya merujuk ke lokal yang sama persis:
- fr_fr.8859-1
- fr_fr.819
- fr_fr.0333
Untuk informasi lebih lanjut, silakan lihat: