PostgreSQL 處理不區分大小寫的數據庫是否與其他數據庫一樣好？

首先，如果我的問題看起來如此幼稚，請原諒我（我不是 DBA）。我查看如何使 PostgreSQL 不區分大小寫，我發現官方文件的 Nondeterministic Collat​​ions 部分很有用。我嘗試了以下方法，但沒有運氣。

CREATE COLLATION ci_fa (provider = icu, locale = 'fa-IR-x-icu', deterministic = false); -- also locale = 'fa-IR' and 'fa-IR.UTF8'

我找到了這個答案，但那裡使用的語言環境並不基於我正在尋找的內容。此外，文件中的範例顯示為：

CREATE COLLATION case_insensitive (provider = icu, locale = 'und-u-ks-level2', deterministic = false);

這很好用，但我在排序時遇到了有線行為。如果我的訂單列中有一個非英文字元，結果會有所不同。當我有a, A,b和非英語字元時，結果是a, A, b。當我有a, A,B和非英語字元時，結果是A, a, B。

另一方面，閱讀大量的文章和問題讓我想知道以下問題？

1. 具有不區分大小寫的數據會影響性能，那麼我應該使用它還是不使用它？考慮以下事實：

• 我 99% 的數據沒有套管。我們的語言更簡單，因此字母中沒有小寫/大寫:)
• 我在使用者可以輸入英文單詞的部分使用全文索引進行搜尋。我不知道我的排序規則將如何影響全文。
• 我不喜歡這裡建議的任何解決方案（如何進行“不區分大小寫”查詢）。
• 雖然我使用的是 EF Core 5，但我有 DB 函式來處理複雜的查詢。

2. 我正處於項目的早期階段，我第一次決定從 SQL Server 遷移到 PostgreSQL。我應該改用 MySQL 嗎？

• 我需要波斯排序規則（不確定我是否這樣做，文件中的排序規則可以很好地處理排序，但我沒有測試儲存它 - 在 CentOs 中）。
• 我需要地理定位。
• 我需要全文。
• 顯然，性能。

當我有 a、A、b 和非英語字元時，結果是 a、A、b。當我有 a、A、B 和非英語字元時，結果是 A、a、B。

這是deterministiccollat​​ion 屬性為 false 的效果。等效字元串之間沒有決勝局，因此a可能會在之前A或相反的情況下出現。數據庫中的排序通常也不穩定，因為在關係理論中，行沒有固有的順序，所以堅持“原始順序”是沒有意義的。

如果您不喜歡這樣，您可以添加帶有確定性排序規則的第二個訂單，例如

ORDER BY field COLLATE "non-deterministic-collation", field COLLATE "C"

我在使用者可以輸入英文單詞的部分使用全文索引進行搜尋。我不知道我的排序規則將如何影響全文。

它沒有。全文搜尋解析器主要受lc_ctype數據庫屬性的影響。tsvector從字元串中提取 a 時，甚至會出現與強制排序相關的特定錯誤：

=> select to_tsvector('abc') collate "C";
ERROR:  collations are not supported by type tsvector

我需要波斯排序規則（不確定我是否這樣做，文件中的排序規則可以很好地處理排序，但我沒有測試儲存它 - 在 CentOs 中）。

創建數據庫時，它確實從模板數據庫繼承排序規則，或者如果明確指定，則從lc_collateor子句中獲取它。locale這是此數據庫中所有排序和字元串比較的預設排序規則。

如果您在帶有fa_IR語言環境的 UTF-8 編碼中使用 Linux，則lc_collate您的數據庫的 可能是fa_IR.UTF-8，因此它確實隱式使用了波斯排序規則。您的問題中沒有明確表明您的應用程序確實需要創建自定義排序規則。

創建排序規則的細節可以在這里和這裡很好，並且可以使用以下創建波斯排序規則。

CREATE COLLATION the_name (provider = icu, locale = 'fa-IR@colStrength=secondary', deterministic = false);

引用自：https://dba.stackexchange.com/questions/284310