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
Related
I'm self learning SQL, using Microsoft Server management and have a question
Let say you have Customer table, Store table and Delivery table. The store needs to update their stocks count every time a Customer purchases a product or a Deliveryis made(INSERT INTO TABLE).
How to update your stock count in Store table whenever a data is Inserted into Customer table and Delivery table? And how do you Insert a New product from Delivery to your Store Table?
I think nested queries is the correct way to do both of these problems but just not sure how to do nested query for INSERT query
It is generally not possible to update multiple fields from multiple tables on a single update query (depends on your DBMS). You can add triggers, e.g. updating the Stock table after an insert on the Delivery or Customer table. If you want these updates to be done at the exact same time, use a transaction.
We are evaluating cloud warehouse options to build a analytics solution. We need to provide trend analysis per day, per customer across many customers (400+), ratio of queries for across these two dimensions are equal. My initial thought is to create Date partitioned table one per customer, so for queries per customer I limit the scan to one particular day and for queries across all customer I use table wildcard feature.
Questions:
Is there a way to partition by Date and customer, so I can store all data in one table and still limit data scan volume?
If ans to #1 is no, What is the performance impact of querying across 400 tables Vs one table (same amount of data)
Hash partitioning and partitioning by specific fields in a table are not supported yet, so this is not feasible now.
If you query the 400 tables using wildcards and filter customers using _TABLESUFFIX, the query will only read the matching tables and you'll only be charged for those tables; if you query one table then you can filter dates using _PARTITIONTIME and you'll only be charged for the matching partitions. Performance wise less metadata is read if you query one table, but that shouldn't be much for 400 tables.
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.
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.
Maybe I'm not good in googling but I'm seeking for a set of gold rules and recommendations in designing databases related to billing.
Lets say I have an SQL table with transactions
transactions(id int, credit float, debit float, billable_account_id int)
Based on the rule of database normalization I abandon the idea of storing and updating on every transaction pre-calculated running balance for every *billable_account_id* in the same table or elsewhere regardless of the size of the transaction table.
I'm using Postgres if that matters(though the subject is common) and I'm not an SQL ninja at all but trying to be pedantic in designing.
Questions:
Am I right going with this approach?
If yes, what methods would you suggest in maintaining such table and in composing query for getting running totals?
Any references are very appreciated!
You can use analytic functions to generate a running total in most databases. In Oracle, something like
SELECT billable_account_id,
SUM( (CASE WHEN credit IS NOT NULL THEN credit
WHEN debit IS NOT NULL THEN -1 * debit
ELSE 0
END) ) OVER (PARTITION BY billable_account_id
ORDER BY transaction_date ) running_total
FROM transactions
If you don't have a TRANSACTION_DATE, you could use ID assuming that you can guarantee that the generated IDs are monotonically increasing.
However, from a performance standpoint, you are likely going to want to bend if not break the third normal form normalization rules for OLAP/ DSS type reporting because people are going to want to report on totals pretty frequently and some accounts are likely to have large numbers of transactions. You may, for example, want to create a separate table that has an ending balance for each BILLABLE_ACCOUNT_ID for each month end and then use the analytic function to just add the current month's transactions to last month's ending balance. In Oracle, you may want to create a materialized view that will automatically maintain the running total.