Bruk av collection.contains() i et LINQ uttrykk tar laaaaaaaang tid

[HDSoftware]

Folkens...

Jeg prøver å bygge et LINQ uttrykk Runtime på bakgrunn av en del propmpts jeg har i en form. Uttrykket brukes for å søke i en tabell over ord/uttrykk som er brukt i dokumenter.  Dette fungerer veldig bra fordi jeg bruker IQUERYABLE. 

Noe slik:

 

var records = from record in dbContext.WordTable

                      Select record;

 

 

Så kommer det en del greier som påvirker ting, som ikke er av interresse, men følgende gir hodepine:

records = records.Where(r => wordsToSearch.Contains(r.Word));

 

WordsToSearch er en List<String> som inneholder alle ordene som skal søkes på. 

 

Dette fungerer, men tar fryktelig lang tid.  Så analyserer jeg det faktiske SELECT statementet og ser følgende (herunder er ordet 'prosesskriv' valgt i GUI:

.....

   WHERE ([Extent1].[Word] IN (N'prosesskriv'))

.....

Legg merke til N som er bygget inn i uttrykket.  Dette betyr jo National character.  Tabellen har 50 milioner records og søket resulterer i 5000 treff og tar over 5 minutter.

Hvis jeg manuellt tester det genererte uttrykket tar det akkurat like lang tid, men fjerner jeg N fra IN uttrykket så får jeg samme resultat, men søket tar 2 sekunder.

 

Jeg tenker jo at N sikkert er viktig i mange situasjoner, men i denne sammenhengen er det kun brukt i Norge og jeg går ut ifra at ingen tenker på å skrive en masse kryptiske tegn når de søker. 

 

Spørsmålet er derfor:  Hvordan får jeg vekk den N fra IN elementene?

 

 

[Enthroner]

skal ikke være bombastisk men jeg tror du må bytte collation så den ser bort i fra alt bortsett fra norske tegn. Nermeste er vel latin1_german2_ci?

Som sagt, jeg er ikke sikker. Skriver dette fra kø på flyplass men kanskje hjelper det deg?

[HDSoftware]

vor bytter jeg Collation ?  Jeg mener, dette genereres jo av klienten - Vet klienten noe om dette da hvis du snakker om SQL server settings ?

 

btw - takker for inlegget...

Endret 20. januar 2016 av HDSoftware

[Enthroner]

Beklager at jeg ikke har kommet tilbake til deg. Jeg gikk ut i fra at du hadde kontroll (og tilogmed da er jeg usikker på om det ville hjulpet...). Har du kontroll på klient så kan det hende du kan sørge for å bruke varchar og ikke nvarchar?

[RulleRimfrost]

Kanskje kompilator synes input er for svakt typet som det er nå, men fjerner N' om du konverterer/caster r.Word før query?

[Enthroner]

// REF http://stackoverflow.com/a/1705311/844397
IQueryable<Word> records = dbContext.WordTable.Select(r=> wordsToSearch.Contains(r));

System.Data.Common.DbCommand command = dbContext.GetCommand(records);

// bytt type fra "string" (nvarchar) til "ansistring" (varchar)
command.Parameters[0].DbType = DbType.AnsiString; 
command.Connection = dbContext.Connection;

//run
IEnumerable<Word> search = dbContext.Translate<Employee>(command.ExecuteReader());

Det beste jeg fant om temaet på det store internettet. Kan du teste det?

 

EDIT: Må si dette er en interessant problemstilling. Post løsning hvis/når du finner en!

Endret 22. januar 2016 av Enthroner

[HDSoftware]

Takker for alle inlegg folkens.  Dere var inne på det.  Det var snakk om datatype.  Utfordringen var at han som kodet domene klassene har bare brukt STRING over en lav sko for å representere tekst data uten å spesifisere hvilken.  Det jeg gjorde for å løse dette var faktisk veldig enkelt:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
  modelBuilder.Entity<TabellName>().Property(r => r.FeltMedString).HasColumnType("VARCHAR");
}

Og vips vaps vups - kjøre tiden ble dramatisk endret.  Nå kjører den samme spørringen på forventet tid

[Enthroner]

Takker for alle inlegg folkens.  Dere var inne på det.  Det var snakk om datatype.  Utfordringen var at han som kodet domene klassene har bare brukt STRING over en lav sko for å representere tekst data uten å spesifisere hvilken.  Det jeg gjorde for å løse dette var faktisk veldig enkelt:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
  modelBuilder.Entity<TabellName>().Property(r => r.FeltMedString).HasColumnType("VARCHAR");
}

Og vips vaps vups - kjøre tiden ble dramatisk endret.  Nå kjører den samme spørringen på forventet tid

 

Elegant og fin løsning  

Trodde du brukte LINQ to SQL, ikke EF - det gjør konfigurasjon lettere. Pent!