0

我有一个具有以下关系的数据库：

Transaction->Purchase->Item->Schedule

Transaction - self explanitory
Purchase - any purchase info that relates to the item being purchased (quantity, if the user purchases more than one item).  A given Transaction can have more than one Purchase_ID tied to it.
Item - Stores Item info and relates it to individual clients.
Schedule - determines the price of an item at a given time of day.

Transaction.TimeStamp我需要执行一个查询，该查询必须根据是否在提供的日期范围内从 Schedule 中选择一系列值。查询需要根据其主键从 Schedule 中选择一个值。主键无法从事务中追踪。

为了解决这个问题，我决定创建一个表来将 Transaction DIRECTLY 链接到 Schedule 的主表。

最近我发现了表格视图——这是否适合制作表格“视图”？还是我应该只创建一个“实际”表TransactionSchedule？

transactionSchedule
Transaction_ID    Schedule_ID

我的问题是我不了解表格视图何时有用/有什么好处的细节。

是否有一个单独的表来跟踪事务->计划过度杀伤？

真的，任何有关此问题的一般指导将不胜感激。

编辑：此查询仅用于检索已输入的数据

- 谢谢

4

2 回答 2

2

我强烈建议您在插入价格后立即将价格从时间表中直接复制到购买中。这样，您就解决了您的问题，同时，如果您意外（或有意）更改了时间表，则可以防止以后向客户收取不同的价格。

至于与日程表的主键有关，并且无法从交易中追溯：那是设计不佳的标志。我的意思是，想想看——你在事务中有一个时间戳，根据定义，一个时间表是使用从和到时间戳及时放置的——你为什么不能把它们联系起来？AFAICS，计划的主键应该是item_id, from_timestamp, to_timestamp

假设您的日程表有一个从和到时间戳我的查询将是

SELECT     ..your columns..
FROM       Transaction t
INNER JOIN Purchase    p
ON         t.id        = p.transaction_id
INNER JOIN Item        i
ON         p.id        = i.purchase_id
INNER JOIN Schedule    s
ON         i.id        = s.item_id
AND        t.timestamp BETWEEN s.from_timestamp
                           AND s.to_timestamp

至于，你是否使用视图——真的，这取决于你。视图不会比查询更好或更差，唯一的区别是定义存储在数据库中。其主要优点是

  • 人们可以在不复制查询（并将其弄乱）的情况下重用定义，
  • you can change the schema to some extent and hide that from the application provided you update the view accordingly (this latter advantage is often overestimated)
于 2010-01-25T18:48:25.943 回答
0

Can't the transaction record have a foreign key linked with the schedule primary key? or is it a many-to-many relationship. Either way I do not see view as appropriate here.

于 2010-01-25T18:53:16.823 回答