I dette særtema ser vi på, hvordan cloud og AI bliver fundamentet for virksomhedernes digitale forretning, og hvordan de nye muligheder for automatisering og forretningsværdi kan udnyttes uden at miste overblik, sikkerhed og menneskelig kontrol.
Du vinder RIGTIG meget ved at definere et index på det. Du skal bare være opmærksom på at det også koster lidt i performence når du indsætter eller opdaterer en række. Men du vinder rigtig meget når du laver et select.
Hvis du kun har tre felter, så bør du også overveje et covering index, dvs. et index på alle tre felter. Det betyder, at al nødvendig information til forespørgslen ligger i indexet, og derved slipper SQL Server for at skulle læse på de fysiske datasider.
Med forbehold for at jeg ikke kender de interne funktioner i MS SQL særlig godt så ved jeg at der i database teorien findes nogle meget stærke index på dato-strukturer, hvor man laver index over et range af datoer i en træ struktur.
Hov stop det hjælper intet at lave et index på den slags søgninger når leftclausen bliver convertet. Så drop dit index på den datetimecol.. det er bare spild af plads.
Men du kan gøre flere smarte ting.. Du kunne eks.vis oprette en hjælpetabel der holdt styr på et evt. minimum og maximum id på hver dato noget i retning af
Populer det med flg. sql: insert into tbl_stat_helper select min(id), max(id), convert(varchar, str_dato, 112) from tbl_stat_login group by convert(varchar, str_dato, 112)
Denne tabel skal så naturligvis vedligeholdes en gang i døgnet.
Når du så skal udvælge noget fra din tbl_stat_login, gør du sådan her: select * from tbl_stat_login sl inner join tbl_stat_help sh on sl.id between sh.min_id and sh.max_id where sh.datestamp = 20040609
Jeg formoder du har en primary key.. derfor bruger jeg bare id ! - Hvis ikke så navngiv den efter din primary key i tabellen tbl_stat_login
Der er en del andre måder som sagt at løse det på, men forsøg at starte med det jeg har vist dig. Og 10M+ er intet at tale om for mssql - bare rolig mand :O)
janus_007> Jeg er godt klar over at det ikke hjælper når der bliver foretaget en convert, men det er heller ikke nødvendigt at lave en convert, så hvorfor ikke bare droppe den istedet for at droppe index'et.
Så kan du gøre sådan Dim strDato, strSQL strDato = "2004-06-09"
strSQL = "DECLARE @dato datetime; SET @Dato = CONVERT(datetime, '" & strDato & "', 120); SELECT * FROM tbl_stat_login WHERE str_dato = @Dato"
osv ...
På den måde konverterer du strengen til datetime én gang, og din SELECT kan køre uden at konvertere, og derfor udnytte indexet. Bemærk dog at du kun får rækker ud hvor klokkeslættet er som i @Dato: 00:00:00.000
ldanielsen -> Det var da en besynderlig løsning, som du skriver giver den jo kun rækker hvor klokkeslettet 00:00:00.000, hvem kan da bruge den slags til noget?
Løsningen giver alle poster hvor str_dato er lig '20040609' som ønsket. Hvad er det besynderlige?
Jeg gør bare opmærksom på at denne query ikke giver alle poster hvor datoen er fra samme dag. Den giver kun poster hvor datoen er PRÆCIS som '20040609', hvilket vil sige 9. Jan 2004 kl. 0:00.0000
Ja præcis på klokkeslettet som du skriver. Det som queryen skulle returnere var alle rækker på en given dato og ikke et givent millisekund. Det var bare det jeg fandt lidt besynderligt at du foreslog.
Hvis gadebarnet har tænkt sig at han vil have alle poster på samme dag, og hvis str_dato kan have klokkeslæt der ikke er 0:00.000, så har vi lavet det helt forkert fra starten.
I givet fald skal det så være sådan, med DATEDIFF:
strSQL = "DECLARE @dato datetime; SET @Dato = CONVERT(datetime, '" & strDato & "', 120); SELECT * FROM tbl_stat_login WHERE DATEDIFF(dd, str_dato, @Dato) = 0"
gadebarnet > det her må du tage stilling til, ok?
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.