La query sull'uguaglianza nella colonna NVARCHAR produce più risultati in SQL Server 2012

Sto trasferendo un progetto per animali da PostgreSQL (9.2.2) a SQL Server (2012 Standard).

Ho notato un fenomeno interessante durante l'interrogazione di parole unicode. Data la definizione:

CREATE TABLE [word](
    [id] [int] IDENTITY(0,1) NOT NULL,
    [value] [nvarchar](255) NULL    
 );

e i dati:

insert into word (value) values (N'ῥύπῳ');
insert into word  (value) values (N'ἀπὸ');
insert into word  (value) values (N'ἀπό');
insert into word (value) values  (N'ἐπὶ');
insert into word (value) values  (N'ἐπί');
insert into word (value) values  (N'ὑπὸ');
insert into word (value) values  (N'ὑπό');
insert into word (value) values  (N'πίῃ');

insert into word  (value) values (N'λόγους');
insert into word  (value) values (N'λόγχῃ');
insert into word (value) values  (N'λόγων');
insert into word  (value) values (N'ἀλόης');

una query per una determinata parola restituirà corrispondenze vicine. Per esempio:

select * from word where value = N'ἀπὸ'

ritorna:

id  value
102137  ῥύπῳ
102141  ἀπὸ
102142  ἀπό
102143  ἐπὶ
102144  ἐπί
102145  ὑπὸ
102146  ὑπό
102147  πίῃ

http://sqlfiddle.com/#!6/1ab66/1

Tuttavia, lo stesso modello in PostgreSQL restituisce solo la corrispondenza esatta. Come posso fare in modo che SQL Server faccia lo stesso?

(Link violino PostgreSQL): http://sqlfiddle.com/#!12/c57a6/1

Ho la netta sensazione che mi manchi qualcosa, ma non riesco a capire di cosa si tratti.

Il confronto del database è SQL_Latin1_General_CP1_CI_AS(che è anche il confronto del server) su un'installazione locale.

sql-server postgresql

— swasheck
fonte

Le regole di confronto determinano la semantica del confronto.

Se ci provo

CREATE TABLE [word](
    [id] [int] IDENTITY(0,1) NOT NULL,
    [value] [nvarchar](255) COLLATE Latin1_General_100_CI_AS NULL    
 );

Ritorna solo ἀπὸ.

Cambiando il suffisso in anche AIper rendimenti insensibili all'accento ἀπό.

Nella mia installazione ho provato ogni confronto e 1526ritorno 1(presumibilmente ASe BINconfronto), 1264restituito 2 righe (presumibilmente AI) e 1095ritorno 8.

Da una rapida occhiata a quest'ultimo gruppo sembra includere tutte le SQLregole di confronto e le regole di 90confronto, mentre tutte 100sono presenti nei primi 2 gruppi, quindi presumo che questo sia un problema risolto nel batch di regole di confronto 2008. (Vedi Novità nelle regole di confronto di SQL Server 2008 )

Script per provarlo tu stesso

DECLARE @Results TABLE
(
Count INT,
Collation SYSNAME
)

SET NOCOUNT ON;
DECLARE @N SYSNAME;
DECLARE @C1 AS CURSOR;
SET @C1 = CURSOR FAST_FORWARD FOR 
SELECT name
FROM sys.fn_helpcollations();
OPEN @C1;
FETCH NEXT FROM @C1 INTO @N ;
WHILE @@FETCH_STATUS = 0
BEGIN
  INSERT @Results
  EXEC('SELECT COUNT(*), ''' + @N + ''' from word where value = N''ἀπὸ'' COLLATE ' + @N)
  FETCH NEXT FROM @C1 INTO @N ;
END

SELECT *
FROM @Results
ORDER BY Count DESC

— Martin Smith
fonte