1

自分が何をしているのかわからないのではないかと心配しています。

1:

ticketという列を持つ というテーブルがありますtotal。合計が更新されたら、その記録 (古い合計など) を保持したいので、列を削除して、列、、およびtotalという名前のテーブルを作成することにしました(もちろん、最新のものは「現在の」合計です)。 .ticket_totalticket_idtotaldatetime

また

2:

その後、クライアントが でチケットをソートしたり、合計を集計するレポートを取得したりできるようにしたいと後で気付きました。そのため、代わりに列をにtotal戻し、合計がが更新されますが、まず前のレコードとして行を作成します。totaltickettotalticket_totaltotal

バージョン 2 は、関連するテーブルをクエリする必要があまりないため、非常に効率的であるように思われますが、ticket_totalDB の達人はどう思うでしょうか。私はちょうどデータベースの設計を学んでいて、それが得意になることはないのではないかと恐れています。

4

4 に答える 4

1

あなたが提案したオプション2を使用します。

整合性が維持されるように、トランザクションで Update (チケットの) + Insert ( ticket_total 内) を実行していることを確認してください。

于 2010-10-04T03:27:12.827 に答える
1

2 番目の方法の方が高速ですが、合計の履歴値に関するレポートを作成する場合は、置き換える値とタイムスタンプを一緒に保存する別のテーブルが必要です。このタイプのテーブルは、監査テーブルと呼ばれます。

于 2010-10-04T03:36:48.280 に答える
1

Re: 「効率」 -- プロジェクトの開始時にデータベースの効率についてあまり心配しないことが最善です。時期尚早の最適化は避けるべきよくある間違いです。

より良いのは、ニーズに焦点を合わせて設計することです。後で、パフォーマンスのボトルネックがどこにあるかをテストして確認し、それらの解決に取り組むことができます。

小規模なデータベース (数万行) の場合、現在のサーバーとソフトウェアを考えると、「非効率的な」クエリでさえ非常に高速になることがよくあります。

シンプルに保つ本当に必要でない限り、キーの組み合わせやテーブル セマンティクスのオーバーロードは避けることをお勧めします。

提案2 種類のデータがあります。現在のチケット情報と、古い「合計」値の履歴テーブルです。

したがって、ver 2 が優先されます。

ticket
  id
  field_a
  field_b
  total    # current_total

ticket_total  # history of ticket total field
  id
  ticket_id
  total
  create_time

また、「合計」は何かの集合体のように聞こえます。よりわかりやすいフィールド名を考えてみることをお勧めします。──フィールド・ア・トータルとは？"total_worktime" ?

追加テーブルのインデックスを追加することを忘れないでください。検索に使用するものでインデックスを作成します。たとえば、チケット テーブルには customer_id がありますか? インデックスされていることを確認してください。

于 2010-10-04T03:41:41.183 に答える
0

ticket_total をテーブルではなくビューにします。別のビュー ticket_current を作成し、最新の日付でチケットをフィルター処理します。つまり、チケット テーブルが ticket_Id と datetime で二重にキー設定されている場合です。そうでない場合は、最後の部分を無視してください。

于 2010-10-04T03:26:38.507 に答える