i have one product table.
in my table there is a fields like productid , price , quantity , total .
than how i multyply price , and quantity fields and the answer stored in the total field.
Don't store derived values in your tables - this is bad design.
Since total is the product of price and quantity, you can always calculate it when you have these values - why store it? You are creating the potential for inconsistent data in your database if you do so.
Retrieving such a value directly from SQL is trivial, without the need to store it:
SELECT price, quantity, price * quantity AS total
FROM product
Update:
As #Martin notes, SQL Server 2005+ has Computed Columns which are non persisted or indexed columns that as a convenience return the results of a calculation.
I stress that these are columns that are not persisted.
You can create a computed column for this
ALTER TABLE Products ADD total AS price * quantity
With the above definition the column is neither persisted nor indexed so it is just a convenience for your queries.
You might consider indexing such a computed column if your queries needed to use total in a search predicate. Any such persisted values are maintained automatically by SQL Server thus avoiding potential issues with data anomalies.
Additionally in the case that you are doing such queries then even without indexing such columns your queries can benefit from improved cardinality estimates due to statistics on the computed column.
Related
I am currently building a management system. Is it good practice to create a balance table for inventory to store the inventory at hand and constantly update the table if there are changes, or should one just directly query total inventory ordered table - total inventory used table? Which would be the most efficient and fastest way to do?
It is likely a bad idea to use two separate tables. You will have to perform a join which is unnecessary. Simply have one table with an 'ordered' column and a 'used' column. In your query you can very efficiently calculate the net value e.g. :
SELECT ordered, used, (ordered - used) as net FROM inventory
I am trying to use this to learn how about data warehousing and having trouble understanding the concept of the fact table.
http://www.codeproject.com/Articles/652108/Create-First-Data-WareHouse
What would be some queries that I could run to find information from the faceable, and what questions do they answer.
A fact table is used in the dimensional model in data warehouse design. A fact table is found at the center of a star schema or snowflake schema surrounded by dimension tables.
A fact table consists of facts of a particular business process e.g., sales revenue by month by product. Facts are also known as measurements or metrics. A fact table record captures a measurement or a metric.
Example of fact table -
In the schema below, we have a fact table FACT_SALES that has a grain which gives us a number of units sold by date, by store and by product.
All other tables such as DIM_DATE, DIM_STORE and DIM_PRODUCT are dimensions tables. This schema is known as the star schema.
Let's translate this a bit.
Firstly, in a fact table we usually enter numeric values ( rarely Strings , char's ,or other data types).
The purpose of a fact table is to connect with the KEYS of dimensional tables ,other fact tables (fact tables more rarely, and also not a good practice) AND measurements ( and by measurements I mean numbers that change frequently like Prices , Quantities , etc.).
Let's take an example:
Think about a row from a fact table as an product from a supermarket when you pass it by the check out and it get's scanned. What will be displayed in the check out row in your database fact table? Possibly:
Product_ID | ProductName | CustomerID | CustomerName | InventoryID | StoreID | StaffID | Price | Quantity ... etc.
So all those Keys and measurements are bringed together in one fact table, having some big performance and understandability advantage.
Fact Table Contain all Primary key of Dimension table and Measure like "Sales Amount"
A Fact table is a table that stores your measurements of a business process. Here you would record numeric values that apply to an event like a sale in a store. It is surrounded by dimension tables which give the measurement context (which store? which product? which date?).
Using the dimensions you can ask lots of questions of your facts, like how many of a particular product have been sold each month in a region.
Some further info
All dimension keys in a fact should be a FK to the dimension
if a key is unknown it should point to a zero key in the dimension detaialing this.
All joins from a fact to a dim are 1 to 1. bridge tables are is a technique to cater for many to many's, but this is more advanced
All measurements in a fact are numeric, but can contain NULLS if unknown (never put 0 to represent unknown)
When joining facts to dimensions there is no need to do an outer join, due to FKS applied above.
if you have 999 rows in a fact, no matter what dimensions you join to, you should always have 999 rows returned.
Can Dimension Table became a fact table as well? For instance, I have a Customer dimension table with standard attributes such as name, gender, etc.
I need to know how many customers were created today, last month, last year etc. using SSAS.
I could create faceless fact table with customer key and date key or I could use the same customer dimension table because it has both keys already.
Is it normal to use Customer Dimension table as both Fact & Dimension?
Thanks
Yes, you can use a dimension table as fact table as well. In your case, you would just have a single measure which would be the count - assuming there is one record per customer in this customer table. In case you would have more than one record per customer, e. g. as you use a complex slowly changing dimension logic, you would use a distinct count.
Given your example, it is sufficient to run the query directly against the Customer dimension. There is no need to create another table to do that, such as a fact table. In fact it would be a bad idea to do that because you would have to maintain it every day. It is simpler just to run the query on the fly as long as you have time attributes in the customer table itself. In a sense you are using a dimension as a fact but, after all, data is data and can be queried as need be.
how do I write a script to change the discount in the Order Details table on all orders of products of an ordered quantity of more than 50 to that of the largest discount ever given on any product.In the northwinds table?
I just need direction, do I use subqueries and how do I get the largest discount?
You're best off using temp tables.
First, select into a temp table the products and their largest discounts.
Next, select into a temp table a list of product instances (I assume there's a key value) with ordered quantities greater than 50.
Lastly, do an update on your Order Details table joined to the two temp tables. Inner joins in both cases.
If you want to make it a single query, you can make those two temp tables into subqueries, but using temp tables is way more efficient. More code, but easier to parse and runs faster.
I would like to make queries on fact table in star schema.
I need to capture lot of values like gross sales net sales regional sales etc for combination of other couple values that is PK.
I have two options:
One row with PK and lot of columns with measures like gross sales, regional sales etc.
make measures as a dimension, so PK would be bigger - there would be added column Measures in row. And only one value beside PK. So I decompose the one row with many Measures to lot of rows with one Measure.
What is better for performance, both insert and select?
You will have contention issues if you have a single row with all the values, assuming you have simultaneous inserts/updates and reads.
Having a single wide table also means it's much more difficult to add new measures in the future - it requires changing the table schema which will lock the table and cause other problems.
Your SELECT performance should be similar, unless you are pulling multiple values for the same PK in the same query, in which case the wider table would probably be a little quicker.
What is your lowest level of granularity in the fact? When you mention things like regional sales and gross net sales it makes me think that you might be confusing measures and dimensions. For example: a region would be a dimension of the sales fact.