View a markdown version of this page

Limitazioni di regole di confronto e differenze di comportamento - Amazon Aurora

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Limitazioni di regole di confronto e differenze di comportamento

Babelfish utilizza la libreria ICU per il supporto delle raccolte. PostgreSQL è costruito con una versione specifica di ICU e può corrispondere al massimo a una versione di un confronto. Le variazioni tra le versioni sono inevitabili, così come le piccole variazioni nel tempo man mano che le lingue evolvono. Nella sezione seguente sono disponibili le limitazioni note e le variazioni di comportamento delle regole di confronto Babelfish:

  • Indici e dipendenza tipo regola di confronto: un indice su un tipo definito dall'utente che dipende dalla libreria di regole di confronto ICU (International Components for Unicode) (la libreria utilizzata da Babelfish) non viene invalidato quando la versione della libreria viene modificata.

  • Funzione COLLATIONPROPERTY: le proprietà delle regole di confronto sono implementate solo per le regole di confronto Babelfish BBF supportate. Per ulteriori informazioni, consulta Babelfish supported collations table.

  • Differenze nelle regole di ordinamento Unicode: le regole di confronto SQL per SQL Server ordinano Unicode-encoded i dati (ncharenvarchar) in modo diverso rispetto ai dati che non lo sono Unicode-encoded (chare). varchar I database Babelfish sono sempre UTF-8 codificati e applicano sempre le regole di ordinamento Unicode in modo coerente, indipendentemente dal tipo di dati, quindi l'ordinamento per char o varchar è lo stesso di o. nchar nvarchar

  • Secondary-equal regole di confronto e ordinamento: le regole di confronto ICU secondary-equal (CI_AS) di default ordinano i segni di punteggiatura e altri caratteri non alfanumerici prima dei caratteri numerici e i caratteri numerici prima dei caratteri alfabetici. Tuttavia, l'ordine di punteggiatura e altri caratteri speciali sono diversi.

  • Regole di confronto terziarie, soluzione alternativa per ORDER BY: le regole di confronto SQL, ad esempio SQL_Latin1_General_Pref_CP1_CI_AS, supportano la funzione TERTIARY_WEIGHTS e la capacità di ordinare stringhe che si confrontano allo stesso modo in una regola di confronto CI_AS da ordinare prima in maiuscolo: ABC, ABc, AbC, Abc, aBC, aBc, abC e infine abc. Pertanto la funzione analitica DENSE_RANK OVER (ORDER BY column) valuta queste stringhe come aventi lo stesso rango, ma le ordina prima in maiuscolo all'interno di una partizione.

    Puoi ottenere un risultato simile con Babelfish aggiungendo una clausola COLLATEalla clausola ORDER BY che specifica una raccolta terziaria CS_AS che specifica @colCaseFirst=upper. Tuttavia, il modificatore colCaseFirst si applica esclusivamente alle stringhe terziarie uguali (piuttosto che secondarie-uguali come una regola di confronto CI_AS). Pertanto, non è possibile emulare raccolte SQL terziarie utilizzando una singola relazione ICU.

    Come soluzione alternativa, consigliamo di modificare le applicazioni che utilizzano la raccolta SQL_Latin1_General_Pref_CP1_CI_AS per utilizzare la raccolta BBF_SQL_Latin1_General_CP1_CI_AS prima di iniziare la raccolta. Quindi aggiungere COLLATE BBF_SQL_Latin1_General_Pref_CP1_CS_ASa qualsiasi clausola ORDER BY per questa colonna.

  • Espansione di caratteri: un'espansione di caratteri tratta un singolo carattere come uguale a una sequenza di caratteri a livello primario. La regola di confronto CI_AS predefinita di SQL Server supporta l'espansione di caratteri. Le regole di confronto ICU supportano l'espansione di caratteri solo per regole di confronto senza distinzione caratteri accentati/non accentati.

    Quando è richiesta l'espansione dei caratteri, utilizzare una raccolta AI per confronti. Tuttavia, tali raccolte non sono attualmente supportate dall'operatore LIKE.

  • Codifica char e varchar: quando le regole di confronto SQL vengono utilizzate per i tipi di dati char o varchar, l'ordinamento per i caratteri precedenti a ASCII 127 è determinato dalla pagina codice specifica per tale regola di confronto SQL. Per le regole di confronto SQL, le stringhe dichiarate come char o varchar potrebbero essere ordinate in modo diverso rispetto alle stringhe dichiarate come nchar o nvarchar.

    PostgreSQL codifica tutte le stringhe con la codifica del database, quindi tutti i caratteri vengono convertiti e ordinati utilizzando le regole Unicode. UTF-8

    Poiché le regole di confronto SQL ordinano i tipi di dati nchar e nvarchar utilizzando regole Unicode, Babelfish codifica tutte le stringhe sul server utilizzando. UTF-8 Babelfish ordina le stringhe nchar e nvarchar nello stesso modo in cui ordina le stringhe char e varchar, usando regole Unicode.

  • Caratteri supplementari: le funzioni SQL Server NCHAR, UNICODE, e LEN supportano i caratteri per i punti di codice al di fuori di Unicode Basic Multilingual Plane (BMP). Al contrario, le raccolte non SC utilizzano caratteri di coppia surrogata per gestire caratteri supplementari. Per i tipi di dati Unicode, SQL Server può rappresentare fino a 65.535 caratteri utilizzando o l'intero intervallo Unicode (1.114.114 caratteri) se vengono UCS-2 utilizzati caratteri supplementari.

  • Kana-sensitive Collazioni (KS): le regole di confronto Kana-sensitive (KS) trattano i caratteri Kana giapponesi in modo diverso. Hiragana Katakana ICU supporta lo standard di raccolta giapponeseJIS X 4061. Il modificatore di localizzazione colhiraganaQ [on | off] oramai obsoleto potrebbe fornire la stessa funzionalità delle raccolte KS. Tuttavia, le raccolte KS con lo stesso nome di SQL Server non sono attualmente supportate da Babelfish.

  • Width-sensitive regole di confronto (WS): quando un carattere a byte singolo (mezza larghezza) e lo stesso carattere rappresentato come carattere a doppio byte (larghezza intera) vengono trattati in modo diverso, le regole di confronto vengono chiamate sensibili alla larghezza (WS). Le raccolte WS con lo stesso nome di SQL Server non sono attualmente supportate da Babelfish.

  • Variation-selector regole di confronto sensibili (VSS): le regole di confronto sensibili (VSS) distinguono tra i selettori di variazione Variation-selector ideografica nelle regole di confronto giapponesi e. Japanese_Bushu_Kakusu_140 Japanese_XJIS_140 Una sequenza di varianti è costituita da un carattere base più un selettore di varianti aggiuntivo. Se non viene selezionata l'opzione _VSS, il selettore delle varianti non è considerato nel confronto.

    Le relazioni VSS attualmente non sono supportate da Babelfish.

  • Regole di confronto BIN e BIN2: una regola di confronto BIN2 ordina i caratteri in base all'ordine dei punti di codice. L'ordine binario byte per byte UTF-8 mantiene l'ordine dei punti di codice Unicode, quindi è probabilmente anche la raccolta con le migliori prestazioni. Se l'ordine dei punti di codice Unicode funziona per un'applicazione, prendere in considerazione l'utilizzo di una raccolta BIN2. Tuttavia, l'utilizzo di una raccolta BIN2 può comportare la visualizzazione dei dati sul client in un ordine culturalmente inaspettato. I nuovi mapping con caratteri minuscoli vengono aggiunti a Unicode man mano che il tempo progredisce, quindi la funzione LOWER potrebbe funzionare in modo diverso su diverse versioni di ICU. Questo è un caso speciale del problema di controllo delle versioni di raccolta più generale piuttosto che come qualcosa di specifico per la raccolta BIN2.

    Babelfish fornisce la raccolta BBF_Latin1_General_BIN2 con la distribuzione Babelfish da collare nell'ordine dei punti di codice Unicode. In una raccolta BIN solo il primo carattere viene ordinato come wchar. I caratteri rimanenti vengono ordinati byte per byte, in modo efficace in ordine di codice in base alla sua codifica. Questo approccio non segue le regole di confronto Unicode e non è supportato da Babelfish.

  • Non-deterministic regole di confronto e limitazione CHARINDEX — Per le versioni di Babelfish precedenti alla versione 2.1.0, non è possibile utilizzare CHARINDEX con regole di confronto non deterministiche. Per impostazione predefinita, Babelfish utilizza una regola di confronto senza distinzione maiuscole/minuscole (non deterministica). L'utilizzo di CHARINDEX per le versioni precedenti di Babelfish genera il seguente errore di runtime:

    nondeterministic collations are not supported for substring searches
    Nota

    Questa limitazione e la soluzione alternativa si applicano solo a Babelfish versione 1.x (Aurora PostgreSQL versioni 13.x). Babelfish 2.1.0 e versioni successive non presentano questo problema.

    Puoi risolvere il problema in uno dei seguenti modi:

    • Converti esplicitamente l'espressione in un confronto con distinzione tra maiuscole e minuscole e trasforma entrambi gli argomenti applicando LOWER o UPPER. Ad esempio, SELECT charindex('x', a) FROM t1 diventa ciò che è indicato qui di seguito:

      SELECT charindex(LOWER('x'), LOWER(a COLLATE sql_latin1_general_cp1_cs_as)) FROM t1

    • Crea una funzione SQL f_charindex e sostituisci le chiamate CHARINDEX con le chiamate alla seguente funzione:

      CREATE function f_charindex(@s1 varchar(max), @s2 varchar(max)) RETURNS int
AS
BEGIN
declare @i int = 1
WHILE len(@s2) >= len(@s1)
BEGIN
  if LOWER(@s1) = LOWER(substring(@s2,1,len(@s1))) return @i
  set @i += 1
  set @s2 = substring(@s2,2,999999999)
END
return 0
END
go