• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 162
  • Last Modified:

Optimising Table SELECTs - whether to use a view and UDF or a computed column

Hi,

I have a relatively complex database for use in a web application.

The tables themselves are fairly simple, with only a few columns of standard datatypes.  However, I am unsure of the most suitable way to proceed with regard to optimisation.

For example, imagine I have a table which stores prices. The table might have columns such as:

ID
UnitPrice
TaxPercentage
Discount

Rather than calculate the "actual" price in the web application, I would rather do this at the database level. In effect, I would like a column such as "TaxPrice" (i.e. UnitPrice * TaxPercentage) or "SalePrice" (UnitPrice - Discount).

As I can see, there are two ways to go.

1. Use a computed column in the table itself.
2. Use a view which has a subquery which returns the necessary value.

At the moment I am using option 2. I have views set up anyway as I am performing various JOINs. I also thought it best to move the subquery to a UDF which returns a scalar value. This has particular attraction since I can abstract out some commonly used functions.

Which is the better approach?  The table rows will be in the region of thousands of rows at most rather than tens of thousands. The selects will generally only be returning 1 - 10 rows at a time, and in the case of large result sets, these will be paged.

For a simple calculation (e.g A - B or A*B) then is the computed column more efficient?

I also have subqueries which reference other tables - obviously I cannot put these into computed columns, but I could use the UDF in the computed column. I would prefer not to do this as it strikes me as probably having high overhead.


0
gw5434
Asked:
gw5434
2 Solutions
 
arnoldCommented:
You have to balance out resource usage.  It is good to calculate and store the data in a view if that will save you from performing repetitive tasks.

However, using a view and the server to calculate the price of buying two units of A at price B for one users while tabulating the price of ten units of A at Price B for another, is a waste of resources.  A calculation of number of item times the price is not an intensive enough transaction to dedicate the SQL server's resources for it can be performed on the server when the data is retrieved.

Creating Views to simplify/speed up repetitive queries are a good use of resources.
I.e. instead of generating join queries, creating an aggregate view of those joins and then querying the view with a limiting where clause could speed up the performance.  Note however, that views often use up system resources when changes to underlying tables occur.

0
 
jorge_torizResearch & Development ManagerCommented:
I preffer to use a computed persisted column, I think your data won't be volatile (a lot of changes)
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.

Join & Write a Comment

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

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

Tackle projects and never again get stuck behind a technical roadblock.
Join Now