Hastighedsforskel på views og almindelige tables i access/mssql

Hejsa

En gammel kollega fortalte mig engang at et view er hurtigere end en table, altså uden nogen modifikation til det view, bare samme indhold som den brugte tabel

Er det rigtigt? Jeg står nemlig tit med nogle ret voldsomme views navne, da jeg altid har et view til tabellen jeg henter fra og nogle gange et eller flere views, hvis jeg skal bruge forskelle udtræk

Hvis der ingen forskel er og det er lige så hurtigt at trække ud fra en tabel som det er fra et view, så ville det da være super meget nemmere, bare at trække det ud fra tabellen, hvis man kun skal hente tabellens data

Så vidt jeg forstå, består et view bare af den SQL kode det er dannet med. Det vil så altså betyde, at når du laver udtræk fra et view der bare er en kopi af en tabel, svarer det til at skrive:

select variabel from (select * from tabel) where betingelse

I stedet for at skrive

select variabel from tabel where betingelse

når du laver udtræk direkte på tabellen.

Jeg kunne ikke forestille mig at det var hurtigere, men jeg må indrømme at jeg ikke har testet det. Kan din kollega forklare hvorfor han mener det er hurtigere?

Noget views tit bliver brugt til er at skjule bagved liggende SQL.

F.eks. istedet for en avanceret join over flere tabeller med group's osv.
Så har man f.eks. 'select * from memberview where id=17' i sin kode, det er langt mere overskueligt, og derved kan du sikre at applikationsudviklerne kun skal tænke på selve kodningen, og en DBA'er roder med SQL'en.

Personligt lavet jeg begge dele, så jeg gider ikke bruge view's :)Rent performancemæssigt ved jeg ikke lige hvad der er hurtigst, men jeg kunne forestille mig view's er compilet på forhånd, og derfor minimalt hurtigere.

#3 det var også noget i den dur han mente.. fordi det allerede er samlet, så hentes det hurtigere ud..

Jeg bruger views så meget som muligt, da det letter koden ubegribeligt meget, i forhold til kun at hente ud fra tables..

Men tror egentlig jeg vil begynde kun at lave views, når der skal trækkes data ud, der f.eks. peger på hinanden, så views kommer til sin ret..

#4
Personligt bruger jeg Stored Procedures i stedet for, da de giver mig flere muligheder.

De er jo ligesom views også compilet.

Generelt vil man forvente at et view er langsommere end direkte adgang til tabellen. En vigtig undtagelse er materialized views.

Jeg er skeptisk overfor genbrug af execution plan argumentet - jeg ville tro at en ny execution plan for den samlede SQL ville være så meget mere effektiv at den ville være det værd.

Jeps den er god nok. SQL Serveren (Jeg formoder at du bruger en version af Access som er ny nok til at være baseret på den) er i stand til at optimere de queries der foretages via et view.

Forskellen på et view og en select statement er, som #6 påpeger ved at tvivle på det, at SQL Serveren optimerer din database via brugsmønstre. Disse brugsmønstre er også grunden til at to identiske databaser kan performe forskelligt, alt efter hvad de har været brugt til (For eksempel udvikling kontra produktions brug).

Det er ikke sikkert du kan se nogen forskel når du ikke har så mange data i din database eller når du ikke har brugt dit view mange gange, men har du en database som er stor nok til at du bekymrer dig om hastigheden og brugt nok til at hastigheden er vigtig, så er det interessant at bruge views.

Brugen af views bliver mere interessant når du joiner tabeller sammen. Ved at bruge views kan du oprette indexer på de kolonner du søger meget på og dermed kraftigt optimere hastigheden på de søgninger der kører på tværs af tabellerne.

Brugte du management studio til din SQL Server, ville du kunne vise en execution plan på dit view, som ville vise hvordan serveren foretog forespørgselen. Kalder du UPDATE STATISTICS vil SQL Serveren optimere databasen udfra de seneste brugsmønstre og ændre din execution plan, hvis det er nødvendigt.