3

私は自分のウェブサイトで宝くじを行う予定なので、チケットと番号を保存する場所が必要です。私は間違いなく、tickets各行が独自のチケットID、関連する宝くじID、およびその他すべての情報（所属するユーザーのIDなど）を持つテーブルを呼び出します。

ただし、私の質問はtickets、チケットで選択した番号を保持するために別のフィールドを作成する必要があるかどうかです。number1などの複数のフィールドを作成することはできません。number2各宝くじには異なる種類のチケットがあるためです (つまりlottery1、4 つの番号を選択するlottery2よう求められ、6 つを選択するよう求められる場合があります)。

したがって、コンマ区切りのチケット番号を受け入れる VARCHAR または TEXT の新しいフィールドを作成するか、または各行にチケット ID とチケット番号が関連付けられた1,2,3,4,5,6別の新しいテーブルを作成することができます。numbersただし、この方法が非常に効率的かどうかはわかりません.6つの数字のチケットが1つだけの場合、テーブルに1行、ticketsテーブルに6行が必要になるためnumbersです。

これらのオプションのどれが最も効率的ですか? または、これよりも良い方法はありますか？宝くじの最後に、コードは各チケットを循環して当選したかどうかを確認する必要があることに注意してください。そのため、オプション 2 はリソースを大量に消費する可能性があります。

4

2 に答える 2

1

以下の「Ticket[Number]」は、「選択された宝くじ番号のセット」を意味します。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 (ラッフル番号など) がキーを形成すると主張します。したがって、これに対する私の議論は次のとおりです。

  1. TicketNumber は、(ラッフルごとに) チケットを一意に識別する不透明な値です。DB モデル内の「詳細を知る」必要はありません。(場合によっては必要になるかもしれませんが、ここではありません。)

  2. DisplayTicketNumber はユーザー入力のアーティファクトです。ただし、複数の DisplayTicketNumbers で同じ TicketNumber を表すことができます。これは「重複」の可能性を表していますが、これは選択された数値のリスト(セットよりも多くの情報を持つ) を表すFriendly Display値であることを理解することが重要です。

    1. このような場合、DisplayTicketNumber(and TicketNumber) をトリガーで不変にして、作成後にデータベースの不整合が発生しないようにします。

    2. FK を計算できる場合は、DisplayTicketNumber と TicketNumber の間の制約を不変性なしで適用できます。

(ラッフルごとに異なる TicketNumber を使用するなど、さまざまな詳細を省略しました。FK の も示していますが、それが許容される [非代理] キーであるTicketIdこともほのめかしています。)RaffleId,TicketNumber

また、Ticket テーブルを削除することもできます。宝くじ番号セットが共有されることはほとんどないため、関連する追加のチケット情報がない場合は、それを削除することで非正規化が許容される可能性があります。これの利点の 1 つは、テーブルTicketNumberに移動してから、Ticket 値を正規化した計算列(まだインデックスが作成されている) に変換できることです。Purchase

また、MySQL が FK での計算列の使用を許可している場合、リレーションシップ-PK(Ticket.TicketNumber) >を使用するとFK(Purchase.TicketNumber)、Purchase.TicketNumberが計算され、Ticket テーブルを削除せずにモデルの整合性を高めることができます。(ただし、MySQL を使用していないため、これが実行可能かどうかはわかりません。)

ハッピーコーディング。

于 2012-07-27T00:33:14.037 に答える
0

番号と呼ばれる新しいテーブルを作成し、それに関連付けられた番号を持つ 2 番目のオプションを使用します。

ただし、選択できる数字の量を示すフィールドと、そのチケットを使用して (クエリで COUNT を使用して) 挿入された数字の量がより少ないかどうかを確認する条件も、チケット テーブルに追加します。選択できる数の量を指定してから挿入します。

于 2012-07-27T00:13:51.657 に答える