2

ハッシュ値とハッシュに関するいくつかのデータをすべて1つのテーブルに格納するデータベースがあります。フィールドの1つは'job_id'です。これは、ハッシュの元となったジョブのIDです。

私が解決しようとしている問題は、この設計では、ハッシュは1つのジョブにしか属することができないということです。実際には、ハッシュは多くのジョブで発生する可能性があり、ハッシュが発生する各ジョブを知りたいのです。

これを行うことを考えている方法は、フィールド「job_id」、「job_name」、および「hash_value」を持つ「Jobs」という新しいテーブルを作成することです。データの新しいバッチがDBに挿入されると、ジョブIDと名前がここに作成され、各ハッシュは元のハッシュテーブルと同様にここに入力されますが、ジョブテーブルにはジョブに対しても保存されます。 。

テーブル間でハッシュ列を複製するので、これは好きではありません。もっと良い方法はありますか？ハッシュテーブルに追加することはできますが、クローズドソースソフトウェアがそれに依存しているため、列を削除することはできません。ハッシュ値が主キーです。それはMySQLであり、データベースには何百万ものレコードが保存されています。前もって感謝します！

4

3 に答える 3

1

私が解決しようとしている問題は、この設計では、ハッシュは1つのジョブにしか属することができないということです。実際には、ハッシュは多くのジョブで発生する可能性があり、ハッシュが発生する各ジョブを知りたいのです。

これを行うことを考えている方法は、フィールド「job_id」、「job_name」、および「hash_value」を持つ「Jobs」という新しいテーブルを作成することです。

a）外部キーの権利とb）「job_id」と「hash_value」の両方のカスケードの権利 も取得できる限り、それで問題ありません。

重複データと冗長データは、リレーショナルモデリングの専門用語です。専門用語 とは、辞書に載っていないような意味を持っていることを意味します。「同じ値が複数のテーブルに表示される」という意味ではありません。値を代理ID番号に置き換えると、それらのID番号が複数のテーブルに表示されるため、これは明らかなはずです。

これらの専門用語は、実際には「同一の意味を持つ同一の値」を意味します。（関連：述語の定義と使用に関するHugh Darwenの記事。）

テキストをID番号に置き換えるには、実用的な理由があるかもしれませんが、理論的な理由はなく、正規化では確かにそれは必要ありません。（「すべての行にID番号がある」という通常の形式はありません。）

于 2013-01-08T15:40:40.337 に答える
1

job新しいテーブルを追加するのが良い方法です。これは、1対多の関係を表すための規範的な慣行です。

値の不必要な重複を避けるのは良いことです。ただし、この場合、実際にはhash_value列を「複製」しているわけではありません。むしろ、主キーとしてjob持つテーブルとの間の関係を実際に定義しているのです。hash_value

関係は、子テーブルに列を追加することによって実装されます。その列は、親テーブルの主キー値を保持します。通常、列にもFOREIGNKEY制約を追加します。

于 2013-01-08T15:42:11.737 に答える
0

私があなたの質問を正しく読んだ場合、これらの2つの事実のために、あなたのデザインは根本的に欠陥があります。

  • ハッシュが主キーです（質問から引用）
  • 同じハッシュを複数の異なる入力から生成できます（ファクト）
  • 何百万ものハッシュがあります（質問から）

何百万もの行/ハッシュがあると、最終的にはハッシュの衝突が発生します。

唯一の正しいアプローチは、主キーとしてjob_idを持ち、一意でないインデックスが付いた列にハッシュを設定することです。ハッシュを指定してジョブを見つけるのは簡単です。

于 2013-01-08T15:41:00.510 に答える