SQL view - indexing help

We get a datafile from a vendor which I want to use for a view and create my own "summary" columns based on multiple columns.  

CASE WHEN LEFT(Status, 2) = "EM" OR Emergency = "Y" THEN "Emergency" ELSE "Standard" END AS 'Recordstatus'

(this is somewhat simplified)

That way the users in Access can simply say "Where recordstatus = 'Emergency' " and it will pull all the necessary combinations.

My question is, should I put an index on the Emergency and the Status column - will that have an effect on the query performance?  

Should it be a combined index or should each column have a separate index?

WedmoreAsked:
Who is Participating?
 
jesusafloresConnect With a Mentor Commented:
And according to your particular case, I think it's best to create it separately. however, in relation to the performance of the query, the answer is yes or no, why?, good text indexes are not desirable because the internal motors of the drivers database indexes are optimized for numeric and date type , that is why we usually do not see an index to a Boolean field, but SQL best practices indicate that if you use multiple columns in a WHERE clause, and these columns are used in many queries or Store Procedures and views should be created because here the indices the perfomaqnce is enhanced, in comparison, but what it had created.

I hope to have helped you.
0
 
8080_DiverCommented:
Why not create a calculated column that handles the CASE statement and provides you with the single column with that result.  Then put that as an indexed column.
0
 
WedmoreAuthor Commented:
I always thought calculated columns should never be stored in a table.
0
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
8080_DiverCommented:
There is a very wise bit of advise regarding databases, tables, and virtually everything else in life:
Never use "always" and always avoid using "never".

If it is the solution to your problem and, in fact, the best solution to your problem, why would you not do it?  Just to conform to an academic rule? ;-)
0
 
batchakamalCommented:
Can you put the whole SELECT query to advise you better index?

Above statement is part of WHERE clause or SELECT clause?

What is your performance priority? Better data manipulation or better retrieval?

If I get these inputs then I hope that I can help you better...
0
 
WedmoreAuthor Commented:
The above statement would be part of the SELECT clause.  The real question is that since I cant index columns in a view, would indexing the columns separately or combined make a difference.

Priority is data retrieval.
0
 
8080_DiverCommented:
You say that you get a data file from a vendor and, apparently, you are loading that data into a SQL Server database which you then link to from Access.  If that is the case, then why can't you add the calculated column to the SQL Server table into which you load the data file and then put an index on that calculated column?  Also, you could add multiple indexes on the SQL Server table (e.g. on Status, Emergency, and the combination of both of those columns) without even having to do the calculated column.  That should allow you to access the data, from Access, via a SQL Query.

For that matter, couldn't you put the query in a stored procedure in the SQL Server database and then execute the stored proc from your Access front end?

Pulling the data from a stored proc on SQL Server would probably be the fastest, having the data and the indexes on SQL Server would probably be next fastest.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.