Home/ Questions/Q 7437757
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T10:26:54+00:00

Everything that isn’t labeled calc or finalvalue is raw data that I will be

  • 0

tables

Everything that isn’t labeled “calc” or “finalvalue” is raw data that I will be manipulating.

I finally know enough SQL to be able to create the necessary tables and perform the needed calculations. However, I just wanted to verify that there is no simpler way to do this, something that would involve fewer tables.

Would it be better to create views instead of actually altering the tables and inserting calculated columns? I don’t actually care about the calculated columns in Table1 and Table2 after I have the final data in Table3. SQL Server 2008.

I should also note that I will be receiving new raw data for Table1 and Table2 every day, and that I plan on appending these records and then appending my new Final Values to Table3 with a date field.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Start here:
    http://support.microsoft.com/kb/283878

    You never want to store calculations directly in a table, the calculations will be done by the queries that generate your data. Table 3 is actually the results of a simple query.

    From what you have above, I would say you have at least the following three tables:

    Customers – contains basic customer data, one row per customer, and some kind of ID that you generate (probably an integer identity column is best, but can be anything you choose).

    Produce (or Products, if you have more than fruit and vegetables) – one row per product containing product information, some kind of ID that you generate (again, integer identity is the best).

    Sales – one row per transaction

    Here’s where things get a little tricky. You could have Sales and SalesItems where sales has a unique row for each transaction and SalesItems contains one row for each product that was purchased in the transaction, but for a really simple system as you appear to have above, you could just get away with a Sales table that has ProductID and CustomerID along with quantity and whatever else you want to store.

    EDIT: It’s a safe bet that a simple system will one day grow into a complicated system, so if I were designing the database I would probably go with separate tables for Sales and SalesItems to make the database more flexible and able to scale better.

    • 0