TL; DR
Không có cái gọi là quan điểm "không liên quan đến nhà cung cấp" đối với Collations, hay thậm chí là "bất khả tri phiên bản", vì việc triển khai của họ - bao gồm cả những khía cạnh nào có thể trở nên vô cảm và quy ước đặt tên của họ - là đặc thù của nhà cung cấp và thay đổi theo thời gian .
Dưới đây là tóm tắt về những gì tôi đã tìm thấy và các chi tiết nằm trong phần dài hơn bên dưới dòng:
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
Như bạn có thể thấy trong bảng xếp hạng, hai trong số bảy RDBMS làm hỗ trợ natively "Case-nhạy cảm và hoạt động Accent-insensitive" qua Collations, mặc dù họ có ước đặt tên khác nhau (và một số khác biệt chức năng khác).
Một RDBMS - PostgreSQL - về cơ bản không hỗ trợ sự kết hợp này, nhưng bạn vẫn có thể đạt được nó bằng cách tước bỏ các dấu bằng unaccent()chức năng bổ trợ.
Bốn RDBMS cuối cùng, hai trong số đó có quy ước đặt tên tương tự cho các tùy chọn, không hỗ trợ về mặt kết hợp này cũng như không có cách nào để thực hiện điều này mà không cần viết chức năng của riêng bạn để xóa dấu / dấu phụ. MySQL cho phép tạo Collations của riêng bạn, nhưng điều đó đòi hỏi bạn phải thêm nó vào kiểm soát nguồn và kết hợp nó vào quy trình thử nghiệm & triển khai của mình để có thể áp dụng cho tất cả các máy chủ trong mọi môi trường (nhưng vẫn là một tùy chọn rất linh hoạt và linh hoạt) . SAP ASE đề cập rằng SAP có thể cung cấp các đơn đặt hàng sắp xếp Unicode bổ sung, nhưng không đề cập đến những gì họ có thể sẵn sàng cung cấp.
Liên quan đến:
Có một lý do tốt cho việc này hay chỉ là của tôi một trường hợp sử dụng hiếm gặp?
Tôi có thể nói rằng khi thực hiện nghiên cứu cho câu trả lời này, tôi đã bắt gặp rất nhiều trường hợp những người muốn phân biệt chữ hoa chữ thường và nhạy cảm với MySQL, nhưng rất ít, nếu có, yêu cầu sự kết hợp mong muốn của bạn.
Tôi muốn có một điều kiện tìm kiếm để sử dụng đối chiếu phân biệt chữ hoa chữ thường nhưng không nhạy cảm nhưng không thể tìm thấy.
...
câu hỏi này là nhà cung cấp / phiên bản bất khả tri
Bạn đã không thành công trong tìm kiếm của mình vì thực sự không có ý nghĩa gì khi tìm kiếm RDBMS dựa trên đặc tả Collation. Đó không phải là cách Collations hoạt động. Và trong khi bạn muốn tiếp cận điều này với tư cách là nhà cung cấp không tin tưởng, thì thực tế là Collations - ít nhất là phần chúng ta tương tác - rất đặc trưng cho nhà cung cấp và không luôn phù hợp với sơ đồ mà bạn đang tìm kiếm .
So sánh và sắp xếp chuỗi rất phức tạp và có nhiều cách khác nhau để thực hiện các quy tắc này. Một phương pháp là có các ánh xạ có tính đến một hoặc nhiều quy tắc. Do đó, bốn kết hợp Nhạy cảm và Không nhạy cảm cho Vỏ và Dấu sẽ tương đương với bốn ánh xạ riêng biệt. Ví dụ: bạn đã thấy điều này trên trang MSDN cho Tên đối chiếu máy chủ SQL . Nếu bạn cuộn xuống, bạn sẽ thấy cột bên trái của biểu đồ là Sort Order ID. Mỗi Collation có một ID khác nhau: SQL_Latin1_General_Cp1_CI_AS= 52 while SQL_Latin1_General_Cp1_CS_AS= 51, mặc dù sự khác biệt duy nhất là ở độ nhạy trường hợp.
Hoặc, nó có thể dựa trên quy tắc, chẳng hạn như những gì Unicode cung cấp thông qua Thuật toán đối chiếu Unicode (UCA). Theo cách tiếp cận này, mọi ký tự được đưa ra, theo mặc định, một hoặc nhiều trọng số. Sau đó, mỗi nền văn hóa / miền địa phương có tùy chọn ghi đè bất kỳ trọng số nào hoặc xóa quy tắc hoặc thêm quy tắc. Thuật toán tính đến bất kỳ quy tắc cụ thể nào của địa phương, và sau đó có khả năng thao túng các trọng số đó dựa trên bất kỳ tùy chọn nào được chọn (độ nhạy, trường hợp này xuất hiện đầu tiên khi thực hiện các loại phân biệt chữ hoa chữ thường, v.v.). Đây là một lý do tại sao thực hiện sắp xếp Unicode chậm hơn một chút so với sắp xếp không Unicode.
Để hiểu được có bao nhiêu tùy chọn thực sự có (nghĩa là độ phức tạp thực tế), hãy xem bản demo này từ dự án ICU (International Components for Unicode):
Bản thử nghiệm đối chiếu ICU
Có 8 lựa chọn riêng biệt để xác định, và một số trong số họ được đại diện trong nhiều yếu tố của tên Collation đặc điểm kỹ thuật mà bạn đang nghĩ đến việc (ví dụ CS, CI, AS, AI, vv). Cho biết có bao nhiêu biến thể, sử dụng cách tiếp cận tệp ánh xạ trong đó mỗi kết hợp có ID riêng sẽ tạo ra hàng ngàn tệp. Nhiều tệp trong số đó sẽ cần được cập nhật bất cứ khi nào có thay đổi trong các ngôn ngữ cụ thể đó hoặc khi tìm thấy lỗi. Đây có lẽ là lý do tại sao chỉ có 75 loại Collations trong SQL Server 2012 (tức là những loại có tên bắt đầu bằng SQL_). Do đó không có sự kết hợp cho _CS_AI.
Và lý do tại sao bạn không thể tìm thấy sự kết hợp đó cho Collations dựa trên UCA? Chà, có 3810 Collations trong SQL Server 2012 không bắt đầu SQL_, vì vậy tổng cộng 3885 Collations. Danh sách đó dường như quá dài để được liệt kê đầy đủ trên một trang web. Nhưng điều này không giải thích đầy đủ lý do tại sao bạn không thể tìm thấy sự kết hợp này cho các nhà cung cấp khác.
Ngoài những gì đã được đề cập (nghĩa là có quá nhiều kết hợp để thực hiện và quá nhiều triển khai để liệt kê), bạn vẫn cần phải tranh luận với các triển khai dành riêng cho nhà cung cấp. Ý nghĩa: không phải tất cả các nhà cung cấp đều cho phép điều chỉnh tất cả các tùy chọn đó và không có quy ước đặt tên tiêu chuẩn cho Collations ngay từ đầu. Ngoài ra, không phải tất cả các nhà cung cấp đều xem các tùy chọn sắp xếp là một phần của Collation: PostgreQuery Collations là thứ tự mặc định cho miền địa phương đã chọn và bạn cần sử dụng ILIKEđể có được so sánh không phân biệt chữ hoa chữ thường. Xem bên dưới để biết thông tin cụ thể của nhà cung cấp.
Máy chủ SQL (Microsoft)
Sự khác biệt giữa những gì bạn đang thấy trên hai trang tài liệu MSDN và truy vấn được cung cấp bởi @MartinSmith trong một nhận xét về câu hỏi (được sửa đổi một chút bên dưới):
SELECT *
FROM sys.fn_helpcollations()
WHERE [name] LIKE '%[_]CS[_]AI%';
là hai trang MSDN đó có liên quan cụ thể đến Bộ sưu tập SQL Server không được dùng nữa, trong khi các bộ sưu tập hiển thị là kết quả của truy vấn đó (888 trong số đó là của SQL Server 2012, SP3) là Bộ sưu tập Windows.
Bắt đầu từ SQL Server 2000, các Bộ sưu tập SQL Server cũ hơn (được tạo trước khi SQL Server có thể truy cập vào Bộ sưu tập Windows) không được chấp nhận và không được cập nhật với các quy tắc hoặc chức năng mới. Ví dụ: bắt đầu trong SQL Server 2012, một bộ Collations đã được thêm vào để hỗ trợ xử lý đúng các chức năng tích hợp cho các ký tự bổ sung (tức là các ký tự UTF-16 còn lại ngoài 65.536 ký tự được xác định ban đầu trong UCS-2 ). Những Collations mới kết thúc trong _SC(như trong S upplementary C haracters).
Tốt nhất là không sử dụng SQL Server Collations - những tên có tên bắt đầu bằng SQL_. Do đó, bạn có quyền truy cập vào nhiều Bộ sưu tập hỗ trợ kết hợp các tùy chọn mà bạn đang tìm kiếm (ví dụ: Case-Sensitive và Accent-Insensitive). Bất cứ khi nào có sẵn, tốt nhất là sử dụng một đầu _SCmiễn là nó có tất cả các tùy chọn khác mà bạn muốn.
Mặc dù SQL Server sử dụng _CS_AIquy ước đặt tên, nhưng không có danh sách tất cả 3810 (kể từ SQL Server 2012). Chỉ có trang Tên đối chiếu Windows liệt kê tất cả các địa điểm và phiên bản và cách thức quy ước đặt tên hoạt động, nhưng đó là nó.
SQL Server cũng hỗ trợ chuyển đổi độ nhạy cả Độ rộng và Kana.
MySQL (được mua bởi Oracle)
Phiên bản MySQL 5.7, tài liệu hướng dẫn các quốc gia mà nó hỗ trợ _ai, _as, _ci, và _cshậu tố (và _bincho đầy đủ), nhưng cũng khẳng định:
Đối với các tên đối chiếu không phân biệt không xác định độ nhạy của dấu, nó được xác định theo độ nhạy trường hợp. Đó là, nếu một tên đối chiếu không chứa _aihoặc _as, _citrong tên ngụ ý _aivà _cstrong tên ngụ ý _as.
Ví dụ, latin1_general_cilà trường hợp không nhạy cảm (và giọng không nhạy cảm, ngầm), latin1_general_cslà trường hợp nhạy cảm (và giọng nói nhạy cảm, ngầm)
Điều này chắc chắn ngụ ý rằng có thể có latin1_general_cs_aiCollation. Tuy nhiên, máy chủ MySQL 5.5.50 mà tôi được tiếp cận với không có bất kỳ collations với nhiều hơn một hậu tố, và hậu tố duy nhất tôi thấy là: _cs, _ci, và _bintrên tổng số 198 Collations. Tôi đã sử dụng lệnh SHOW COLLATION để liệt kê chúng.
Vì vậy, mặc dù nghe có vẻ như MySQL sử dụng quy ước đặt tên tương tự (ít nhất là theo hai tùy chọn đó), tôi không thể tìm thấy Collation khớp với những gì bạn đang tìm kiếm. Tuy nhiên, có thể loại bỏ các dấu (và các dấu phụ khác) và sử dụng _csđối chiếu để có được những gì bạn muốn (tương tự như cách bạn sẽ làm trong PostgreQuery - xem bên dưới). Nhưng tôi không chắc về lựa chọn này và không có thời gian để nghiên cứu thêm.
HOẶC , bạn có thể tạo Collation của riêng mình để thực hiện chính xác những gì bạn muốn. Không giống như các RDBMS khác, MySQL dường như làm cho việc thêm Collations của riêng bạn trở nên khá đơn giản, trong trường hợp đó bạn có toàn quyền kiểm soát trọng số của từng ký tự. Vui lòng xem Thêm một đối chiếu đơn giản vào bộ ký tự 8 bit và thêm đối chiếu UCA vào bộ ký tự Unicode để biết thêm chi tiết.
Để biết thêm thông tin về cách MySQL xử lý các loại Collation khác nhau, vui lòng xem trang Loại thực hiện đối chiếu của chúng .
PostgreSQL
Các bộ sưu tập trong PostgreSQL dường như kém linh hoạt hơn nhiều. Bạn chỉ rõ chỉ văn hóa / ngôn ngữ: en_US, de_DE, vv Xin vui lòng xem trang tài liệu của họ cho Collation Hỗ trợ để biết chi tiết. Do đó, theo mặc định, bạn có các phần ghi đè dành riêng cho văn hóa, nhưng Collations thì ngược lại mọi thứ đều nhạy cảm (điều này, không giống như đối chiếu "nhị phân").
Bạn có thể sử dụng ILIKE (mục 9.7.1) để có được độ nhạy cảm trường hợp, nhưng chúng không có toán tử tương tự cho độ nhạy của dấu. Tuy nhiên, tôi thấy rằng chúng có một chức năng không rõ ràng có thể được sử dụng để loại bỏ các dấu và các dấu phụ khác. Xin lưu ý rằng chức năng này là Mô-đun được cung cấp bổ sung và do đó không nhất thiết phải có trong bất kỳ máy chủ PostgreQuery cụ thể nào để sử dụng. Đó là tài liệu liên kết gần đây nhất nêu:
Khi xây dựng từ phân phối nguồn, các thành phần này không được xây dựng tự động, trừ khi bạn xây dựng mục tiêu "thế giới"
...
Nếu bạn đang sử dụng phiên bản đóng gói sẵn của PostgreQuery, các mô-đun này thường được cung cấp dưới dạng gói phụ riêng biệt, chẳng hạn như postgresql-đóng góp.
Vui lòng xem tài liệu đó để được hướng dẫn cách nhận chức năng đó nếu bạn không có nó và muốn có nó.
Thông tin thêm cũng có thể được tìm thấy trong câu trả lời Stack Overflow sau đây:
PostgreQuery có hỗ trợ các bộ sưu tập không nhạy cảm với các điểm nhấn không?
DB2 (IBM)
Tương tự như Microsoft SQL Server, DB2 có hai loại Collations:
Bộ sưu tập "HỆ THỐNG", được chỉ định bằng định dạng sau : SYSTEM_{codepage}_[optional-territory]. Chúng không linh hoạt và dường như không hỗ trợ độ nhạy phù hợp với vỏ, dấu hoặc bất cứ thứ gì. Bạn có thể tìm thấy danh sách Bộ sưu tập được hỗ trợ tại đây: Mã vùng lãnh thổ và trang mã được hỗ trợ
Các đối chiếu dựa trên thuật toán đối chiếu Unicode (UCA). Những điều này hỗ trợ khá nhiều may đo. Vui lòng xem trang đối chiếu dựa trên Thuật toán đối chiếu Unicode để biết chi tiết về cách định cấu hình hành vi, quy ước đặt tên và danh sách các địa điểm hợp lệ. Xin lưu ý rằng trong Bảng 1, ví dụ ở hàng thứ ba ("Cấp độ trường hợp") bắt đầu bằng:
Đặt thuộc tính Cấp độ trường hợp thành bật và thuộc tính Sức mạnh thành cấp chính sẽ bỏ qua dấu nhưng không phải trường hợp.
Đó chính xác là những gì bạn đang tìm kiếm. Nhưng, cú pháp cho điều đó là :
CLDR181_EO_S1. Và đây là lý do tại sao việc tìm kiếm của bạn không tìm thấy bất cứ điều gì liên quan đến DB2.
Oracle
Oracle 10g đã thêm hỗ trợ để thực hiện các so sánh và phân loại không nhạy. Tuy nhiên:
- họ chỉ có các tùy chọn để biểu thị các hoạt động "không nhạy cảm":
_CIvà_AI
- bạn chỉ có thể chỉ định một trong những tùy chọn đó tại một thời điểm
- tùy chọn không phân biệt chữ hoa chữ thường -
_CI- vẫn có dấu nhạy
- tùy chọn không nhạy cảm -
_AI- "luôn luôn không phân biệt chữ hoa chữ thường." (trích dẫn từ tài liệu của họ được liên kết dưới đây)
Vui lòng xem trang tài liệu Tìm kiếm Chuỗi và Sắp xếp Ngôn ngữ của họ để biết thêm chi tiết và ví dụ.
SAP ASE (trước đây là Sybase ASE, còn gọi là Sybase)
ASE hỗ trợ một hoặc nhiều kết hợp độ nhạy sau đây cho mỗi bộ ngôn ngữ / ký tự:
- phân biệt chữ hoa chữ thường
- không phân biệt chữ hoa chữ thường
- không phân biệt chữ hoa chữ thường, nhạy cảm với giọng nói, theo thứ tự
- không phân biệt chữ hoa chữ thường
Bạn có thể thấy mối quan hệ giữa ngôn ngữ, bộ ký tự và các thứ tự sắp xếp có sẵn trên trang Chọn thứ tự sắp xếp mặc định của chúng . Và bạn có thể xem danh sách đầy đủ các Bộ sưu tập trên trang Tên và ID đối chiếu của họ .
Quy ước đặt tên Collation của họ là tùy ý ở chỗ chúng có tất cả 4 - 8 ký tự và cố gắng nắm bắt tên miền hoặc trang mã và một số ý nghĩa của việc sắp xếp. Ví dụ:
altnoacc== "CP 850 thay thế - không có dấu"
rusdict== "Đặt hàng từ điển tiếng Nga"
dynix== "Đặt hàng ngữ âm tiếng Trung"
Có một lưu ý khi họ chọn trang Thứ tự sắp xếp Unicode mặc định :
Bạn có thể thêm các thứ tự sắp xếp bằng cách sử dụng các tập tin bên ngoài trong $/collate/Unicodethư mục. Tên và ID đối chiếu được lưu trữ trong syscharsets. Tên của các thứ tự sắp xếp Unicode bên ngoài không cần phải có syscharsetstrước khi bạn có thể đặt thứ tự sắp xếp Unicode mặc định.
...
Các đơn hàng sắp xếp Unicode bên ngoài được cung cấp bởi SAP. Không cố gắng tạo các đơn hàng sắp xếp Unicode bên ngoài.
Không rõ liệu SAP có cung cấp một thứ tự sắp xếp bên ngoài để cho phép Phân biệt chữ hoa chữ thường và không nhạy cảm hay không. Có thể một ngày nào đó tôi sẽ gửi email cho họ và hỏi nếu có thể được yêu cầu.
Để có được sự kết hợp mong muốn của độ nhạy, bạn nên có thể tạo một hàm vô hướng do người dùng xác định để loại bỏ các dấu và các dấu phụ khác.
Informix (được mua bởi IBM)
Informix dường như chỉ hỗ trợ hành vi sắp xếp và so sánh mặc định của Collation. Do đó Collations chỉ là miền địa phương và bộ ký tự. Phân biệt chữ hoa chữ thường được xử lý ở cấp cơ sở dữ liệu và theo mặc định chúng phân biệt chữ hoa chữ thường. Bạn có thể đặt cơ sở dữ liệu (không phải bảng, hoặc cột hoặc truy vấn hoặc thậm chí là một vị từ) không phân biệt chữ hoa chữ thường bằng cách chỉ định NLSCASE INSENSITIVE trong CREATE DATABASEcâu lệnh.
Mặc dù Collation cơ sở dữ liệu - ngôn ngữ và bộ ký tự - có thể được ghi đè trên mỗi kết nối máy khách, nhưng dường như không có cách nào để ghi đè cài đặt phân biệt chữ hoa chữ thường. VÀ, NLSCASEtùy chọn có "NLS" trong tên vì một lý do: nó chỉ ảnh hưởng NCHARvà NVARCHARdữ liệu; CHARvà VARCHARluôn luôn phân biệt chữ hoa chữ thường.
Độ nhạy của dấu không được xử lý, cũng không có chức năng tích hợp để loại bỏ các dấu / dấu phụ.
Quy ước đặt tên của Informix Collation là:
<lang>_<country>.<code set>
Ở đâu:
<lang> = mã ngôn ngữ 2 chữ cái hoặc 3 chữ cái<country> = mã quốc gia hoặc mã vùng gồm 2 chữ cái<code set> = trang mã được chỉ định theo một trong 3 cách tương đương sau:
- tên: 8859-1
- giá trị thập phân của số CCSID của IBM: 819
- giá trị thập lục phân của số CCSID của IBM: 0333
Do đó, ba thông số kỹ thuật miền địa phương sau đây đều đề cập đến cùng một miền địa phương:
- fr_fr.8859-1
- fr_fr.819
- fr_fr.0333
Để biết thêm thông tin, vui lòng xem: