TL; DR
Harmanlamaların "satıcı-agnostik" görünümü, hatta "sürüm-agnostik" görünümü yoktur, çünkü uygulamaları - hangi yönlerin duyarsız hale getirilebileceği ve adlandırma kuralları dahil - satıcıya özgüdür ve zamanla değişir .
İşte bulduğum şeyin bir özeti ve ayrıntılar satırın altındaki daha uzun bölümde:
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
Grafikte de görebileceğiniz gibi, yedi RDBMS'den ikisi yerel olarak "Büyük / küçük harfe duyarlı ve farklı adlandırma kurallarına (ve diğer birçok işlevsel farklılığa) sahip olmalarına rağmen, Harmanlama yoluyla " işlemleri .
Bir RDBMS - PostgreSQL - bu kombinasyonu yerel olarak desteklemez, ancak aksanları unaccent()eklenti işleviyle çıkararak bunu başarabilirsiniz .
İkisi seçenekler için benzer bir adlandırma kuralına sahip olan son dört RDBMS, bu kombinasyonu yerel olarak desteklemez ya da aksanları / aksan işaretlerini kaldırmak için kendi işlevinizi yazmadan bunu başarmanın bir yolu yoktur. MySQL kendi Harmanlamalarınızı oluşturmanıza izin verir, ancak daha sonra kaynak kontrolüne eklemenizi ve test ve dağıtım işleminize dahil etmenizi gerektirir, böylece tüm ortamlardaki tüm sunuculara uygulanabilir (ancak yine de çok havalı ve esnek bir seçenek) . SAP ASE, SAP'nin ek Unicode sıralama siparişleri sağlayabildiğinden bahseder , ancak ne sunmak istediklerinden bahsetmez.
İle ilgili olarak:
Bunun için iyi bir neden var mı yoksa benimki nadir bir kullanım durumu mu?
Bu cevap için araştırma yaparken, MySQL için büyük / küçük harfe duyarsız ve aksan duyarlı olmak isteyen birçok insanla karşılaştığımı söyleyebilirim, ancak eğer varsa, istediğiniz kombinasyonu isteyin.
Büyük / küçük harfe duyarlı, aksanı duyarsız bir harmanlama kullanmak için bir arama koşulu istedim ancak bulamadım.
...
bu soru satıcı / sürüm agnostik
Bir Harmanlama belirtimine dayalı bir RDBMS aramak gerçekten mantıklı olmadığından aramanızda başarısız oldunuz. Harmanlama bu şekilde çalışmaz. Buna satıcı-agnostik olarak yaklaşmak isterken, gerçek şu ki, Harmanlamalar - en azından etkileşimde bulunduğumuz kısım - çok satıcıya özgüdür ve her zaman aradığınız şemaya uymaz .
Dize karşılaştırma ve sıralama oldukça karmaşıktır ve bu kuralları gerçekleştirmenin farklı yolları vardır. Bir yöntem, bir veya daha fazla kuralı dikkate alan eşleşmeler yapmaktır. Dolayısıyla, Vaka ve Vurgular için dört Hassas ve Duyarsız kombinasyonu dört ayrı eşleme anlamına gelir. Örneğin, SQL Server Harmanlama Adı için bu MSDN sayfasında gördünüz . Aşağı kaydırırsanız, grafiğin sol sütununun olduğunu görürsünüz Sort Order ID. Her bir Harmanlamanın farklı bir kimliği vardır: SQL_Latin1_General_Cp1_CI_AS= 52 iken SQL_Latin1_General_Cp1_CS_AS= 51, tek fark büyük / küçük harfe duyarlılıkta olsa da.
Veya Unicode'un Unicode Harmanlama Algoritması (UCA) aracılığıyla sundukları gibi kural tabanlı olabilir. Bu yaklaşımda, her karakter varsayılan olarak bir veya daha fazla ağırlık verilir. Ardından, her kültür / yerel ayar bu ağırlıklardan herhangi birini geçersiz kılma veya kuralları kaldırma veya kural ekleme seçeneğine sahiptir. Algoritma, bölgeye özgü kuralları dikkate alır ve daha sonra bu ağırlıkları seçilen seçeneklere (duyarlılık, büyük / küçük harfe duyarlı türler yaparken ilk sırada gelir) dayalı olarak manipüle eder. Unicode sıralama yapmanın Unicode olmayan sıralamadan biraz daha yavaş olmasının bir nedeni budur.
Gerçekten kaç seçenek olduğunu (yani gerçek karmaşıklığı) anlamak için ICU (Uluslararası Unicode Bileşenleri) projesinden bu demoya göz atın:
YBÜ Harmanlama Demosu
Orada belirtmek için 8 ayrı seçenek vardır ve bunlardan bazıları (örneğin olduğumuzu düşünmek Harmanlama adı şartname birden unsurları temsil olsun CS, CI, AS, AI, vs). Kaç varyasyon olduğu göz önüne alındığında, her kombinasyonun kendi kimliğine sahip olduğu eşleme dosyası yaklaşımını kullanmak binlerce dosyayla sonuçlanır. Belirli bir dilde değişiklik olduğunda veya hata bulunduğunda bu dosyaların çoğunun güncellenmesi gerekir. Muhtemelen SQL Server 2012'de bu tür Harmanlamalardan yalnızca 75 tane vardır (yani adları ile başlayanlar SQL_). Bu nedenle bir kombinasyon yok _CS_AI.
Ve UCA tabanlı Harmanlamalar için bu kombinasyonu bulamamanızın nedeni? Peki, SQL Server 2012'de başlamayan 3810 Harmanlama vardır SQL_, bu nedenle toplam 3885 Harmanlama vardır. Bu liste bir web sayfasında tam olarak numaralandırılamayacak kadar uzun görünüyor. Ancak bu, diğer satıcılar için bu kombinasyonu neden bulamadığınızı tam olarak açıklamıyor.
Daha önce bahsedilenlerin ötesinde (yani uygulanacak çok fazla kombinasyon ve listelenecek çok fazla uygulama), yine de satıcıya özgü uygulamalarla uğraşmanız gerekir. Anlamı: Tüm satıcılar tüm bu seçeneklerin uyarlanmasına izin vermez ve ilk etapta Harmanlama için standart adlandırma kuralı yoktur. Ayrıca, tüm satıcılar sıralama seçeneklerini Harmanlamanın bir parçası olarak görmez: PostgreSQL Harmanlamaları seçilen yerel ayar için varsayılan sıralamadır ve büyük / ILIKEküçük harfe duyarlı olmayan bir karşılaştırma elde etmek için kullanmanız gerekir . Satıcıya özgü bilgi için aşağıya bakın.
SQL Server (Microsoft)
Bu iki MSDN dokümantasyon sayfasında gördükleriniz ve @MartinSmith tarafından soruyla ilgili bir yorumda sağlanan sorgu arasındaki fark (aşağıda biraz revize edilmiştir):
SELECT *
FROM sys.fn_helpcollations()
WHERE [name] LIKE '%[_]CS[_]AI%';
bu iki MSDN sayfasının özellikle çok kullanımdan kaldırılmış SQL Server Harmanlamalarına atıfta bulunurken, bu sorgu sonucunda ortaya çıkan harmanlamalar (SQL Server 2012, SP3'ten 888 tanesi) Windows Harmanlama'dır.
SQL Server 2000'den başlayarak, eski SQL Server Harmanlamaları (SQL Server'ın Windows Harmanlamalarına dokunmadan önce oluşturulmuştur) kullanımdan kaldırılmıştır ve yeni kurallar veya işlevlerle güncellenmemektedir. Örneğin, SQL Server 2012'den başlayarak, Tamamlayıcı Karakterler için yerleşik işlevlerin uygun şekilde işlenmesini destekleyen bir dizi Harmanlama eklendi (yani, başlangıçta UCS-2'de tanımlanan "taban" 65,536 karakterin ötesinde kalan UTF-16 karakterleri) ). Bu yeni Harmanlamalar sona ermektedir _SC( S tamamlayıcı C karakterlerinde olduğu gibi).
Bu en iyisidir değil isimleri ile başlayan olanlar - SQL Server harmanlamalar kullanın SQL_. Bu nedenle, aradığınız seçeneklerin kombinasyonunu destekleyen çok sayıda Harmanlamaya erişebilirsiniz (örn. Büyük / Küçük Harfe Duyarlı ve Vurgulu Duyarsız). Kullanılabilir olduğunda, _SCistediğiniz diğer tüm seçeneklere sahip olduğu sürece bir ucu kullanmak en iyisidir .
SQL Server _CS_AIadlandırma kuralını kullanırken, 3810 (SQL Server 2012 itibariyle) Windows Harmanlamalarının hiçbir listesi yoktur. Yalnızca tüm yerel ayarları ve sürümleri ve adlandırma kuralının nasıl çalıştığını listeleyen Windows Harmanlama Adı sayfası var, ancak hepsi bu.
SQL Server ayrıca Genişlik ve Kana duyarlılığının değiştirilmesini de destekler.
MySQL (Oracle tarafından satın alındı)
MySQL sürüm 5.7, dokümantasyon o desteklendiği iddialarının devletler _ai, _as, _cive _csekleri (ve _binbütünlüğü için) değil, aynı zamanda devletler:
Aksan duyarlılığı belirtmeyen ikili olmayan harmanlama adları için büyük / küçük harf duyarlılığı ile belirlenir. Bir harmanlama adı içermiyorsa Yani, eğer _aiya _as, _ciadından da anlaşılacağı içinde _aive _csadından da anlaşılacağı içinde _as.
Örneğin, latin1_general_cibüyük / küçük harf duyarsız mı (ve aksan duyarlı değil, dolaylı) latin1_general_csbüyük / küçük harfe duyarlı mı (ve aksan duyarlı, dolaylı olarak)
Bu kesinlikle bir latin1_general_cs_aiHarmanlamanın mümkün olduğunu ima eder . Ancak, ben erişimi olduğunu MySQL 5.5.50 sunucu birden fazla sonek ile herhangi alfabe yoktur ve sadece gördüğüme son ekleri şunlardır: _cs, _cive _bin198 toplam Harmanlamalar karşısında. Listelemek için SHOW COLLATION komutunu kullandım.
Bu nedenle, MySQL benzer bir adlandırma kuralı (en azından bu iki seçeneğe kadar) kullanıyor gibi görünse de, aradığınızla eşleşen bir Harmanlama bulamıyorum. Bununla birlikte, aksanları (ve diğer aksan işaretleri) _cskaldırmak ve istediğinizi elde etmek için bir harmanlama kullanmak mümkün olabilir ( PostgreSQL'de nasıl yapacağınıza benzer - aşağıya bakın). Ancak bu seçenekten emin değilim ve şu anda daha fazla araştırma yapacak zamanım yok.
VEYA , tam olarak istediğinizi yapmak için kendi Harmanlamanızı oluşturabilirsiniz. Diğer RDBMS'lerin aksine, MySQL kendi Harmanlamalarınızı eklemeyi oldukça kolaylaştırıyor gibi görünüyor, bu durumda her karakterin ağırlığı üzerinde tam kontrol sizde. Daha fazla bilgi için lütfen 8 Bit Karakter Kümesine Basit Harmanlama Ekleme ve Unicode Karakter Kümesine UCA Harmanlama Ekleme konusuna bakın.
MySQL'in farklı Harmanlama türlerini nasıl ele aldığı hakkında daha fazla bilgi için lütfen Harmanlama Uygulama Türleri sayfasına bakın.
PostgreSQL
PostgreSQL'deki harmanlamalar çok daha az esnek görünmektedir. Yalnızca kültür / yerel belirtin: en_US, de_DEvs. için kendi dokümantasyon sayfasına bakın Harmanlama Destek detaylar için. Bu nedenle, varsayılan olarak kültüre özgü geçersiz kılmalar alırsınız, ancak Harmanlamalar aksi takdirde her şeye duyarlıdır (bu arada, "ikili" harmanlama ile aynı değildir ).
Büyük / küçük harf duyarsızlığı elde etmek için ILIKE (bölüm 9.7.1) kullanabilirsiniz, ancak aksan duyarlılığı için benzer bir operatörleri yoktur. Ancak, onlar bir var olduğu tespit unaccent aksan ve diğer aksanlı işaretleri kapalı şerit için kullanılabilir fonksiyonu. , Bu işlevi olduğuna dikkat edin Ek Sağlanan Modülü dolayısıyla ve değil ille kullanımına herhangi bir PostgreSQL sunucusunun mevcut. En son bağlantılı belgeler şunları belirtir:
Kaynak dağıtımından oluştururken, "dünya" hedefi oluşturmadıkça bu bileşenler otomatik olarak oluşturulmaz
...
PostgreSQL'in önceden paketlenmiş bir sürümünü kullanıyorsanız, bu modüller genellikle ayrı bir alt paket olarak sunulur, örneğin postgresql-contrib.
Eğer bu işleve sahip değilseniz ve istiyorsanız, bu belgeyi nasıl alacağınıza ilişkin talimatlar için lütfen bu belgelere bakın.
Daha fazla bilgi aşağıdaki Yığın Taşması yanıtında da bulunabilir:
PostgreSQL “aksan duyarlı” harmanlamaları destekliyor mu?
DB2 (IBM)
Microsoft SQL Server'a benzer şekilde, DB2'de iki tür Harmanlama vardır:
Aşağıdaki biçimi kullanılarak belirtilir "SİSTEM" Harmanlamalar,: SYSTEM_{codepage}_[optional-territory]. Bunlar çok esnek değildir ve büyük / küçük harf duyarlılığına, duruma, aksanlara veya herhangi bir şeye uyum sağlamayı desteklemiyor gibi görünmektedir. Desteklenen Harmanlamaların listesini burada bulabilirsiniz: Desteklenen bölge kodları ve kod sayfaları
Unicode Harmanlama Algoritması (UCA) Tabanlı Harmanlamalar. Bunlar biraz terziliği destekliyor. Onların bakınız Unicode Harmanlama Algoritma tabanlı alfabe davranışı, adlandırma kuralı ve geçerli bölgelerin listesine yapılandırma hakkında ayrıntılar için sayfa. Tablo 1'de üçüncü satırdaki ("Vaka Düzeyi") örneğin şunlarla başladığını lütfen unutmayın:
Vaka Düzeyi özniteliğini açık ve Güç özniteliğini birincil düzeye ayarlamak aksanı yoksayar.
Tam da aradığınız şey buydu. Ama, bu sözdizimi şöyledir:
CLDR181_EO_S1. Bu nedenle aramanız DB2 ile ilgili bir şey bulamadı.
torpil
Oracle 10g, aksanı duyarsız karşılaştırmalar ve sıralama için destek ekledi. Ancak:
- yalnızca "duyarsız" işlemleri belirtme seçeneklerine sahiptir:
_CIve_AI
- bu seçeneklerden bir kerede yalnızca birini belirtebilirsiniz
- büyük / küçük harfe duyarsız seçenek -
_CI- hala aksan duyarlı
- aksan duyarsız seçenek -
_AI- "her zaman büyük / küçük harf duyarlı değildir." (aşağıda bağlantısı verilen dokümanlarından alıntılanmıştır)
Daha fazla ayrıntı ve örnek için lütfen Dil Sıralama ve Dize Arama belgeleri sayfasına bakın.
SAP ASE (eski adıyla Sybase ASE, diğer adıyla Sybase)
ASE, her bir yerel ayar / karakter kümesi için aşağıdaki hassasiyet kombinasyonlarından birini veya daha fazlasını destekler:
- büyük / küçük harfe duyarlı, aksan duyarlı
- büyük / küçük harfe duyarlı olmayan, aksan duyarlı
- büyük / küçük harfe duyarsız, aksan duyarlı, tercihli sipariş
- büyük / küçük harfe duyarlı değil, aksanlı
Yerel Sıralama, karakter kümesi ve kullanılabilir sıralama düzenleri arasındaki ilişkiyi Varsayılan Sıralama Düzeni Seçme sayfasında görebilirsiniz. Harmanlamaların tam listesini Harmanlama Adları ve Kimlikleri sayfalarında görebilirsiniz.
Onların Harmanlama adlandırma kuralı, tüm 4 - 8 karakter olmaları ve yerel ad veya kod sayfasını ve sıralamanın bir anlamını yakalamaya çalışmaları nedeniyle keyfidir. Örneğin:
altnoacc== "CP 850 Alternatif - aksan yok"
rusdict== "Rusça sözlük sıralaması"
dynix== "Çince fonetik sıralaması"
Varsayılan Unicode Sıralama Düzeni Seç sayfalarında şunları belirten bir not vardır :
$/collate/UnicodeDizindeki harici dosyaları kullanarak sıralama siparişleri ekleyebilirsiniz . İsimler ve harmanlama kimlikleri içinde saklanır syscharsets. syscharsetsVarsayılan Unicode sıralama düzenini ayarlayabilmeniz için harici Unicode sıralama siparişlerinin adlarının olması gerekmez .
...
Harici Unicode sıralama siparişleri SAP tarafından sağlanır. Harici Unicode sıralama siparişleri oluşturmaya çalışmayın.
SAP'nin Büyük / Küçük Harfe Duyarlı ve Aksan Duyarsızlığına izin vermek için harici bir sıralama düzeni sağlayıp sağlamayacağı belirsizdir . Belki bir gün onlara e-posta göndereceğim ve bir talep olup olmadığını soracağım.
Hassasiyetlerin istenen kombinasyonunu elde etmek için aksanları ve diğer aksan işaretlerini çıkarmak için skaler kullanıcı tanımlı bir işlev oluşturabilmelisiniz .
Informix (IBM tarafından satın alındı)
Informix çoğunlukla bir Harmanlamanın varsayılan sıralama ve karşılaştırma davranışını destekliyor gibi görünüyor. Dolayısıyla Harmanlamalar sadece yerel ayar ve karakter kümesidir. Büyük / küçük harf duyarlılığı veritabanı düzeyinde işlenir ve varsayılan olarak büyük / küçük harf duyarlıdır. Sen tarafından küçük harf duyarsız olması için bir veritabanı (bir tablo veya bir sütun ya da bir sorgu, hatta bir yüklemi) ayarlayabilirsiniz NLSCASE duyarsız belirterek yılında CREATE DATABASEaçıklamada.
Veritabanı Harmanlaması - yerel ayar ve karakter kümesi - istemci bağlantısı başına geçersiz kılsa da, büyük / küçük harfe duyarlılık ayarını geçersiz kılmanın bir yolu yoktur. VE, NLSCASEseçeneğin adı "NLS" bir nedenle: sadece etkiler NCHARve NVARCHARveri; CHARve VARCHARher zaman büyük / küçük harfe duyarlıdır.
Vurgu hassasiyeti ele alınmaz ve aksan / aksan işaretlerini çıkarmak için yerleşik bir işlev yoktur.
Informix Harmanlama adlandırma kuralı:
<lang>_<country>.<code set>
nerede:
<lang> = 2 harfli veya 3 harfli dil kodu<country> = 2 harfli ülke veya bölge kodu<code set> = aşağıdaki eşdeğer 3 yoldan biriyle belirtilen kod sayfası:
- isim: 8859-1
- IBM CCSID numarasının ondalık değeri: 819
- onaltılı değer IBM CCSID numarası: 0333
Bu nedenle, aşağıdaki üç yerel ayar özelliklerinin tümü tam olarak aynı yerel ayarı ifade eder:
- fr_fr.8859-1
- fr_fr.819
- fr_fr.0333
Daha fazla bilgi için lütfen bakınız: