有关拍卖数据库架构的问题

时间:2009-12-02 08:34:45

标签: mysql database-design

我正在查看以下db model,我对此有一些疑问。我确信这是一个很好的设计,因为它背后的人似乎合格,尽管有些事情没有意义:

  1. 为什么他把竞标者和卖家分开了?我以为你有用户,用户可以出价和出售物品。您将有一个参考用户的出价表和一个参考用户表的拍卖表。他在他的教程中谈了很多关于确保模型可扩展并准备好进行更改的例子(例如,没有状态列,在另一个表中有状态并参考)所以这里有什么?
  2. 为什么他们的字段像“计划关闭日期”和“赢家”。这个数据是不是重复,因为计划的结束日期可以使用上次出价时间计算(对于使用自动延期的动作),而获胜者只是拍卖结束时的最后一次出价..?
  3. 仅供参考:我正在尝试从头开始在PHP / MySQL中建立我自己的拍卖网站并且它证明是非常困难的,所以关于这个的教程会很棒!

    谢谢!

2 个答案:

答案 0 :(得分:1)

关于“计划结束日期”和“获胜者”:
是的,数据重复,但在某些情况下,您必须忍受这一点才能正确扩展。

当然,您可以使用“出价”表中的最后出价时间来计算拍卖的结束日期,但如果您的网站变得非常大,那么每次有人加载“拍卖”时您都不想计算很快就会结束“列表 - 因为你必须每次都为每一次有效的拍卖计算它,只是为了找到即将结束的少数几种。  (并且这个列表会被加载很多,相信我!)。

与获胜者相同 - 如果您在拍卖中获得信息,则加载速度更快 表格,因此您不必总是加入“出价”表格,并从每次拍卖的最后一次出价中获取用户 想想“我的易趣”中的页面,其中显示了您在过去60天内赢得的所有拍卖 - 您必须在每次有人加载此列表时搜索所有拍卖的所有出价!

完全规范化的数据库并不总是最好的解决方案,如果您希望它可以与大量用户一起扩展。

答案 1 :(得分:1)

  

他为什么要将竞标者和卖家分开?

每个表都有特定于每个表的唯一列,因此他将它们分开。我实际上会向用户提供用户和子类型的出价工具和卖家,例如:

TABLE User (UserID (PK), ... all common fields for any user)
TABLE Bidder (UserID (PK,FK) ... all fields specific to bidders)
TABLE Seller (UserID (PK,FK) ... all fields specific to sellers)