Bedste performance ved joins

Jeg har blot min personlige mening, men jeg tror i en så lille applikation at du lige så godt kan bruge views, bare for at kunne beholde den store fleksibilitet.

SQL server laver jo lige som med sprocs også en execution plan til views, der kan genbruges af din applikation.

Ja, naturligvis vil tabellerne vokse, men vi taler måske om gennemsnitligt 200 poster pr. tabel om måneden, så det vil ikke være voldsomme mængder.

med så få poster er det formentligt ligegyldigt hvordan du laver de forespørgsler

generelt er jeg lidt bekymret over performance for "multi level" queries så jeg er
ikke så glad for 1 query--N view--M table når vi snakker performance

Det eneste du kan gøre for at forbedre performance er, at oprette de rigtige indekseringer, dog ignorerer MS SQL indekseringer for tabeller med kun 1000-1500 rækker og nedefter, da det ikke kan betale sig performance-mæssigt.

Views forbedre ikke umiddelbart performance - det er jo blot SELECT-statements. Dog kan MS SQL arbejde med indekserede views, men så kan man lige så godt indeksere tabellerne og undgå views.

kommer indexerede views ikke først i Sql server 2005?

Det skulle meget gerne være tilstede fra 2000: http://www1.us.dell.com/content/topics/global.aspx/power/en/ps4q00_microsoft?c=us&cs=555&l=en&s=biz

Hmmm - jeg er skeptisk :-)
Mener de ikke bare at den bruger indexes fra de tabeller view'et selecet'er fra.

Hvis det kan lade sig gøre i 2000, ville det være fedt. Men jeg har aldrig stødt på at man kan...

Jeg testede lige med:
CREATE INDEX IDX_TEST ON testview ([test_id])

Så får jeg en fejl. Har du et stump sql der viser hvordan man laver de indexes? For så skal jeg nok bøje mig :-)

Jeg har aldrig brugt det selv, da jeg mener at man kan gøre det ligeså godt uden indexerede views, og derfor bør undgå dem - keep it simple. På følgende link forklarer de brugen af dem: http://www.databasejournal.com/features/mssql/article.php/10894_2119721_3

Og med den udtalelse mener jeg, at man kan opnå en mindst lige så god performance uden views som med og derfor bør undgå dem i det hele taget, med mindre man anvender dem af sikkerhedsmæssige eller andre årsager.

Indexerede views kan dog vise sig meget nyttige, hvis man står med et eksisterende system der skal opdateres, og ikke har muligheden for at omstrukturere tabeller mv. MS SQL kan nemlig gøre brug af indexerede views på eget initiativ - de medtages i query plannerens overvejelser...

Argh - jeg mente ikke opdateres, men _optimeres_ :-)

Jeg må vidst hellere få lidt mere kaffe indenbors...

Okay, men det vil vel gå lidt hurtigere at lave et view, der kompileres på forhånd og allerede er parset for syntaksfejl, når det skal bruges - fremfor at have hele forespørgslen i applikationskoden?

det er sådan set problemet

den optimale strategi når et view betragtes alene er ikke nødvendigvis den
optimale strategi når flere views skal joines sammen

ikke-indekserede views parses så vidt jeg ved hver gang de anvendes.

Hmm... det troede jeg ikke.

Der står lidt om views i det første link jeg postede, f.eks.:

"These views are used primarily to restrict users to a certain subset of data in one or more base tables for security reasons, and to enable developers to customize how users can logically view data stored in base tables."

Views er altså generelt ikke tænkt til brug ved optimeringer. Og:

"Nonindexed views are materialized at runtime. Any computations such as joins or aggregations are done during query execution for each query referencing the view."

Ok, men jeg kan heller ikke finde ud at lave et indekseret view.

Tak for hjælpen. Læg bare nogle svar.

Svar.

.

følgende virker iøvrigt fint i MSDE 2000:

set quoted_identifier on
go
set arithabort on
go
select * from t1
go
create view v1 with schemabinding as select f1,f2 from dbo.t1
go
select * from v1
go
create unique clustered index ixv1f1 on v1(f1)
go
select * from v1
go
drop view v1
go

Er det en god idé at lave clustered index på primærnøgler?

Det er det ofte. Et clustered index angiver den rækkefølge data ligger placeret på harddisken. Det betyder, at hvis du joiner på primærnøglen vil data være meget hurtige for databasen at læse - den skal ikke hente data forskellige steder fra på disken.