2

定期的に処理し、結果をテーブル B に保存しているエントリを含むテーブル A があります。次に、A の各エントリについて、B の最新の処理日を決定したいと思います。

私の現在の実装では、両方のテーブルを結合し、最新の日付を取得しています。ただし、代替の、おそらく柔軟性の低いアプローチは、日付をテーブル A に直接格納することです。

両方のケース（パフォーマンス、スケーラビリティなど）の長所と短所を考えることができますが、まだそのようなケースはありませんでした。スタックオーバーフローの誰かが同様の状況にあり、どちらかの推奨事項があるかどうかを確認したいと思います特定の理由。

以下は簡単なスキーマ設計です。

Table A
id, some-data, [possibly-here-last-process-date]

Table B
fk-for-A, data, date

ありがとう

4

4 に答える 4

2

説明に基づくと、テーブルBは履歴（またはアーカイブ）テーブルであり、バッチごとに入力されているようです。

表Aはそのままにして、idとdateのインデックスを導入します。履歴テーブルが大きい場合は、テーブルBに自動インクリメントPKを導入し、B-PkidをA-pkidにマップする別のテーブルを用意します。

私はウェアハウステーブルのUPDATEのファンではないため、CURRENT_INDを推奨しませんでしたが、それは代替手段です。

于 2012-09-30T15:43:37.863 に答える
1

これはかなり典型的な質問です。合理的な答えはたくさんありますが、正しいアプローチは 1 つだけです (私の意見では)。

基本的に、「スキーマを非正規化する必要がありますか?」と尋ねています。本当に必要な場合にのみ、スキーマを非正規化する必要があると思います。現在または予想される状況下で、実際のクエリにパフォーマンスの問題があることを証明できるからです。

よく調整されたデータベースを備えた最新のハードウェアでは、結合を実行してテーブル B の最新のレコードを見つけても、膨大な量のデータがない限り、パフォーマンスに顕著な影響を与えることはほとんどありません。

したがって、私の推奨事項は次のとおりです。テスト システムを作成し、2 つのテーブルにシステムが必要とする量の 2 倍のデータを入力し、本番環境でクエリを実行します。クエリ プランを確認し、クエリやインデックス作成を最適化できるかどうかを確認します。本当にうまくいかない場合は、テーブルを非正規化してください。

これは大変な作業のように思えるかもしれませんが、非正規化は大きな問題です。私の経験では、適度に複雑なシステムでは、非正規化されたデータ スキーマが多くのばかげたバグの中心にあります。新しい開発者の導入が難しくなり、アプリケーション レベルでの複雑さが増し、余分なコードはより多くのメンテナンスを意味します。あなたの場合、テーブル A を更新するコードが失敗すると、それを知らずに偽の結果が生成されます。検出されないバグは、多くのデータに影響を与える可能性があります。

于 2012-09-30T19:56:26.840 に答える
0

プロジェクトの最新の状態がテーブルに保存され、プロジェクトの履歴がテーブルに保存されるプロジェクト追跡システムでも同様の状況がありましprojectsた。プロジェクトに新しい更新がある場合は常に、最新の更新番号を見つけてそれに 1 を加えて、次の更新のシーケンス番号を取得する必要があります。列でテーブルをグループ化して を取得することでこれを行うこともできましたが、プロジェクトの更新の数 (数十万) と更新の頻度を考慮すると、コストが高くなります。そのため、値をテーブル自体の列に格納し、特定のプロジェクトに新しい更新があるたびに更新し続けることにしました。HTH。(Cols: project_id, description etc.,)project_history(Cols: project_id, update_id, description etc.,)project_historyproject_idMAX(update_id)projectsmax_update_id

于 2012-09-30T14:45:47.627 に答える
-1

私の理解が正しければ、各行がパラメーターであるテーブルと、各パラメーター値の履歴を時系列で記録する別のテーブルがあります。それが正しければ、私は現在、私が構築している製品の 1 つで同じ状況にあります。私のパラメーター テーブルはメジャー (29K レコード) のリストをホストし、履歴パラメーター値テーブルには 1 時間ごとにそのパラメーターの値が含まれているため、テーブルには現在 4M 行があります。任意の時点で、履歴よりも最新の値に対する要求がはるかに多いため、パラメーター値テーブルの最後のレコードに加えて、最新の値をパラメーター テーブルに保存します。これはデータの重複のように見えるかもしれませんが、パフォーマンスの観点からは完全に理にかなっています。

  1. すべてのパラメーターとその現在の値のリストを取得するために、結合を行う必要はありません。さらに重要なことは、
  2. このような巨大なテーブルから各パラメーターの最新の値を取得する必要はありません

そうです、あなたの場合、私は間違いなく最新の値を親テーブルに保存し、新しいデータが入るたびに更新します。新しいデータの書き込みは少し遅くなりますが、読み取りは非常に高速です。

于 2012-09-30T15:00:12.607 に答える