| Author |
Topic |
|
emundorf
Starting Member
15 Posts |
Posted - 2005-07-28 : 09:37:26
|
| Why would you want to define a formula for a column in a table? This table has upwards of 4000 rows, as is mostly queried through a View. I know this is a vague question, but I can't seem to find any real information on what the benefits of the formula is. I can surmise a few reasons, but I also believe it would be used for reasons due to not understanding how to store and query data in a transactional system.Thanx!Ed |
|
|
spirit1
Cybernetic Yak Master
11752 Posts |
Posted - 2005-07-28 : 09:40:33
|
you mean a computed column?they're used in views to simplfy data retreival...what more info would you like?Go with the flow & have fun! Else fight the flow |
 |
|
|
emundorf
Starting Member
15 Posts |
Posted - 2005-07-28 : 09:53:02
|
| When desiging a table, there is the ability to define a formula attribute. I don't believe that this is the same as a computed column in a view. In the scenario that I am dealing with, everytime a certain table is queried, one of the columns must be calculated for every row returned based on the formula defined for that column.ed |
 |
|
|
spirit1
Cybernetic Yak Master
11752 Posts |
Posted - 2005-07-28 : 09:59:18
|
from BOL:quote: computed_column_expressionIs an expression defining the value of a computed column. A computed column is a virtual column not physically stored in the table. It is computed from an expression using other columns in the same table. For example, a computed column can have the definition: cost AS price * qty. The expression can be a noncomputed column name, constant, function, variable, and any combination of these connected by one or more operators. The expression cannot be a subquery.Computed columns can be used in select lists, WHERE clauses, ORDER BY clauses, or any other locations in which regular expressions can be used, with the following exceptions: - A computed column cannot be used as a DEFAULT or FOREIGN KEY constraint definition or with a NOT NULL constraint definition. However, a computed column can be used as a key column in an index or as part of any PRIMARY KEY or UNIQUE constraint, if the computed column value is defined by a deterministic expression and the data type of the result is allowed in index columns. For example, if the table has integer columns a and b, the computed column a+b may be indexed, but computed column a+DATEPART(dd, GETDATE()) cannot be indexed because the value may change in subsequent invocations. - A computed column cannot be the target of an INSERT or UPDATE statement. Note Each row in a table can have different values for columns involved in a computed column, therefore the computed column may not have the same value for each row.The nullability of computed columns is determined automatically by SQL Server based on the expressions used. The result of most expressions is considered nullable even if only non-nullable columns are present because possible underflows or overflows will produce NULL results as well. Use the COLUMNPROPERTY function (AllowsNull property) to investigate the nullability of any computed column in a table. An expression expr that is nullable can be turned into a non-nullable one by specifying ISNULL(check_expression, constant) where the constant is a non-NULL value substituted for any NULL result.
Go with the flow & have fun! Else fight the flow |
 |
|
|
emundorf
Starting Member
15 Posts |
Posted - 2005-07-28 : 10:33:44
|
| I did view the BOL topic on computed columns, but this does not answer my question of why you would want to do create a formula for a table column.ed |
 |
|
|
spirit1
Cybernetic Yak Master
11752 Posts |
Posted - 2005-07-28 : 11:01:34
|
to help with the calculations in the future...it's a virtual column anyway...so instead of doing the calculation with a view or in a select query the sql server does it's own calcualtion.basicaly... to make your life easier. Go with the flow & have fun! Else fight the flow |
 |
|
|
Kristen
Test
22859 Posts |
Posted - 2005-07-28 : 11:10:03
|
How about having a column in a table that was "PriceEach * Quantity" - would that be a valid example?And if the answer to that is YES then my advice is not to do it - calculate it with a trigger and store it in a physical column (or create a VIEW). Computed Columns hit all sorts of brick walls - make a VIEW onto the table from another database, and now you'll find that you can't do an INSERT into that View - not even if you explicitly name all the columns and leave the computed one out.And all those ARITH_ABORT settings start to rear their heads, don't they?<shudder>Kristen |
 |
|
|
emundorf
Starting Member
15 Posts |
Posted - 2005-07-28 : 11:17:17
|
| I don't think I'm being clear here. Open up EM and select a table. Right-click and enter design mode. Select a column. The bottom of the dialog shows the attributes for the currently selected column. Notice the "Formula" attribute.I understand the purpose of computing a column in a query, like: Select cola + colb as "colab" from... But are you saying that the "FORMULA" is a view which does not get stored in the table? Would it not be more efficient not declare the column and to simply create a view that performs the calculation, instead of designing a table with the calculation? I'd imagine that performance would be decreased by explicitly declaring the derived column. If I have a table with 100,000 rows, everytime I query the table, a function will be called for each row. This does not seem to be very efficient.Thanks for your patience with this question!!!ed |
 |
|
|
emundorf
Starting Member
15 Posts |
Posted - 2005-07-28 : 11:22:13
|
| Kristen,That is exactly what I am talking about. So you are confirming my feelings about the use of a "FORMULA" being less than optimal. Can you give me a reason why someone would want to use a formula? I can't really find any documentation that talks about them.Ed |
 |
|
|
Kristen
Test
22859 Posts |
Posted - 2005-07-28 : 11:24:08
|
| All the Formula facility, in EM, does is to create that column as a Computed Column (which is as Sprit and I have described above)Kristen |
 |
|
|
Kristen
Test
22859 Posts |
Posted - 2005-07-28 : 11:26:43
|
| Well it centralises the way that "PriceEach * Quantity" is calculated - no chance for it to be calculated different in different parts of the application.And you can put an INDEX on itAnd they don't take up valuable disk space in the record (but the index will, obviously)But I hate them from bitter experience!Kristen |
 |
|
|
emundorf
Starting Member
15 Posts |
Posted - 2005-07-28 : 11:27:28
|
| Ok.Thanks Spirit and Kristen!!! Sometimes I have to hear things in a specific way before it gets into my head. Thanks for the patience!Ed |
 |
|
|
|