php - 组织这些表+行的最有效方法是什么？ - MySQL

Question

我要在我的网站上运行彩票，因此需要有一个地方来存储彩票和号码。我肯定会有一个名为 tickets 的表，其中每一行都有自己的票证 ID、相关联的彩票 ID 和所有其他信息(例如它所属的用户的 ID)。

但是，我的问题是我是否应该在 tickets 中创建另一个字段来保存在 ticket 上选择的号码。不能创建多个字段，例如 number1、number2 等，因为每个彩票都有不同类型的彩票(即 lottery1 可能会问你选择 4 个号码，lottery2 可能会要求你选择 6 个)。

所以我可以创建一个新字段，该字段是 VARCHAR 或 TEXT 以接受以逗号分隔的票号，即:1,2,3,4,5,6 或创建另一个新表称为 numbers，其中每一行都有与之关联的票证 ID 和编号。但是我不确定这种方法是否非常有效，至于一张 6 号票，tickets 表中需要 1 行，numbers 中需要 6 行 表。

以下哪个选项最有效？或者有比这更好的方法吗？请记住，在彩票结束时，代码需要循环遍历每张彩票以检查他们是否中奖 - 因此选项 2 可能太占用资源了。

Answer 1

在下面的“Ticket[Number]”中，应理解为“选定的 Set 彩票号码”。请记住 Set(a,b,c) 等于 Set(c,b,a)。

---

我希望它是这样的:

Purchase
  -PersonID // associate Person (one person can have many purchases)
  -TicketID // associate Ticket (a purchase is for one "ticket",
            //                   which can be purchased many times)
  -DisplayTicketNumber // for Human Display

Ticket
  -TicketNumber

即Purchase:M-1:Ticket

DisplayTicketNumber 是用户选择的数字，例如"3,1,2"而另一方面，TicketNumber 是规范化的票号，其中小值排在前面。因此，最终形式是 min,..,max 或类似形式。也就是说，具有相同值集(以任何顺序)的任何数量的 DisplayTicketNumbers 都将具有相同的 TicketNumber:

DisplayTicketNumber  TicketNumber
1,2,3                1,2,3
2,3,1                1,2,3
3,2,1                1,2,3
3,2,1,4              1,2,3,4 .. and etc

然后在 TicketNumber 上放置一个索引，这样一个简单的 WHERE TicketNumber = @normalizedTicketNumber 将是一个非常快速的索引。

我实际上认为这是一个可以接受的规范化设计，TicketNumber(连同抽奖号码)构成了一个 Key。因此，我对此的论点是:

1. TicketNumber 是一个不透明的值，它唯一地标识一张票(每个抽奖事件)。人们不需要“了解数据库模型内部的细节”。 (在某些情况下可能需要，但这里没有。)

2. DisplayTicketNumber 是用户输入的产物；然而多个 DisplayTicketNumbers 可以代表同一个 TicketNumber。虽然这确实代表了可能的“重复”，但重要的是要认识到这是代表列表(包含更多信息)的友好显示值比一组)选择的数字。

   1. 在这种情况下，我会让 DisplayTicketNumber(和 TicketNumber)对触发器不可变，这样在创建之后，就不会在此处引入数据库不一致.

   2. 如果可以计算 FK，则可以在不可变的情况下强制执行 DisplayTicketNumber 和 TicketNumber 之间的约束。

(我省略了各种细节，比如不同的莱佛士有不同的 TicketNumbers 等。我还显示了 FK 的 TicketId，但我也暗示了 RaffleId,TicketNumber是可接受的[非代理]键。)

此外，可以删除 Ticket 表:因为很少有彩票号码集会被共享，所以如果没有额外的关联 Ticket 信息，那么删除它可能是可以接受的 非规范化。这样做的一个好处是 TicketNumber 可以移动到 Purchase 表中，然后变成一个计算列(仍然有索引)规范化 Ticket 值。

并且，如果 MySQL 允许在 FK 中使用计算列，然后使用关系 PK(Ticket.TicketNumber) -> FK(Purchase.TicketNumber) ，其中计算了 Purchase.TicketNumber，可以用于提高模型的完整性，而无需消除 Ticket 表。 (然而，我不使用 MySQL，所以我不能说这是否可行。)

快乐编码。