SQL Server Indexing Strategy -


i'm building web application using sql server 2008 , having difficulty coming best indexing strategy given our use-case. example, of tables structured similar following:

create table jobs  (    id int identity(0, 1) not null,    cmpyid int not null default (0),    statusid int not null default (0),    name nvarchar(100) null,    isdeleted bit not null default (0),     constraint [pk_dbo.jobs]        primary key nonclustered (id asc))  create clustered index ix_jobs_cmpyidandid      on jobs (cmpyid, id)  create index ix_jobs_cmpyidandstatusid     on jobs (cmpyid, statusid) 

in our application, users separated different companies results in queries looking similar following:

select *  jobs  cmpyid = @cmpyid , ... 

additionally, jobs accessed statusid (canceled = -1, pending = 0, open = 1, assigned = 2, closed = 3), similar following:

select *  jobs  cmpyid = @cmpyid    , statusid >= 0    , statusid < 3 

would better off using composite clustered index shown above, or should use default clustered index on id field , create separate index cmpyid?

for statusid column, correct in assuming filtered index way go?

i'm considering partitioning table cmpyid or statusid, not sure best (or if no partition best).

this kinda premature optimization. can spend lot of time worrying 1 net faster database, when live in production, when have best chance of optimizing indexes.

sql server has traces see queries being ran , taking longest. can test out different indexing strategies when live in production no risk. @ worst can slow application down.

i typically setup clustered indexes on primary key. , non clustered on important columns. works jvm stack used sql server. don't know bottle necks going without having data see it.


Comments

Popular posts from this blog

get url and add instance to a model with prefilled foreign key :django admin -

android - Keyboard hides my half of edit-text and button below it even in scroll view -

css - Make div keyboard-scrollable in jQuery Mobile? -