需要有关如何构建我的数据库 (SQL Server) 的帮助
未标记为“calc”或“finalvalue”的所有内容都是我将要操作的原始数据。
我终于了解了足够的 SQL，能够创建必要的表并执行所需的计算。然而，我只是想验证是否没有更简单的方法来做到这一点，即涉及更少的表。
创建视图而不是实际更改表并插入计算列会更好吗？在获得表 3 中的最终数据后，我实际上并不关心表 1 和表 2 中的计算列。 SQL Server 2008。
我还应该注意，我每天都会收到 Table1 和 Table2 的新原始数据，并且我计划附加这些记录，然后将新的最终值附加到带有日期字段的 Table3。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从这里开始：
http://support.microsoft.com/kb/283878
您永远不想将计算直接存储在一个表，计算将由生成数据的查询完成。表3实际上是一个简单查询的结果。
从上面的内容来看，我想说您至少有以下三个表：
客户 - 包含基本客户数据，每个客户一行，以及您生成的某种 ID（可能整数标识列是最好的，但也可以是任何你选择的东西）。
农产品（或产品，如果您有的不仅仅是水果和蔬菜） - 每个产品一行包含产品信息，您生成的某种 ID（同样，整数标识是最好的）。
销售 - 每笔交易一行
这是事情变得有点棘手的地方。您可以拥有 Sales 和 SalesItems，其中 sales 对于每个交易都有一个唯一的行，而 SalesItems 对于交易中购买的每个产品都包含一行，但是对于如上面所示的非常简单的系统，您可以直接使用包含 ProductID 和 CustomerID 以及数量以及您想要存储的任何其他内容的销售表。
编辑：可以肯定的是，一个简单的系统有一天会成长为一个复杂的系统，因此，如果我设计数据库，我可能会为 Sales 和 SalesItems 使用单独的表，以使数据库更加灵活并且能够更好地扩展。
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.