データ構造を作成していましたが、テーブルの 1 つに明確な一意性がありません。
支払いエントリを保持するためのテーブルです (したがって、2 つのエントリが同じである可能性があります)。
リンクされますが、1 対多ベースになります。つまり、口座番号 = x のすべての行を返す
表示に使用され、更新は行われず、挿入のみが削除されます。
このテーブルに主キーが必要かどうかを検討するのをやめました。私の大学は、すべてのテーブルに主キーが必要であると断固として主張しました。そのため、彼は (シーケンスを使用して) 増分 ID を追加しました。
私にとってこれは、リソースを使用していて実際には何も貢献していないシーケンスがあることを意味します。テーブルにインデックスが作成されますが、これは決して使用されませんが、オーバーヘッドが発生します。緊急時に特定の 1 行を削除する必要が生じた場合は、組み込みの ROWID を使用できます。
テーブルにはPKが必要なのはわかっていますが、すべてのテーブルに本当にPKが必要ですか? 何か不足していますか？お時間をいただきありがとうございます。
テーブルにはほぼ確実に主キーが必要です。そして ID 番号は答えではありません。
主キーまたはそれに相当するもの。(NOT NULL UNIQUEたとえば、制約。)
ID 番号がないと区別できない場合は、ID 番号があれば別のものと区別できません。
キーがないと、支払いエントリのテーブルは次のようになります。
account_id payment_type payment_amount
--
10167 cash $10.00
10167 cash $10.00
10167 cash $10.00
10167 cash $10.00
支払いに関するよくある質問には、次のようなものがあります。
「4」と 40.00 ドルと答えたくなるかもしれません。しかし、それらのエントリのうち 2 つは重複しています。(おそらくプログラミング エラーです。「Hello, world」という言葉に挑戦される日もあります。この複雑なことを常に正しく理解しているとは期待できません。)
元のテーブルを ID 番号を取るように変更すると、このような結果になります。
id account_id payment_type payment_amount
--
1 10167 cash $10.00
2 10167 cash $10.00
3 10167 cash $10.00
4 10167 cash $10.00
そして、2 つの重複したエントリがあることはまだわかりません。
より哲学的な視点を提供させてください...
テーブルは、関係を物理的に表現したものにすぎません。また、任意のタプルが関係に存在できるのは最大で 1 回です (関係は集合であり、要素は集合に属することも属さないこともできます。複数回属することはできません)。
キーがないため、個々の行を区別できないため、同じ論理タプルを表す複数の物理行が存在する可能性があります。システムに有用な情報を追加しているのではなく、スペースを浪費しているだけです。
あなたの特定の状況では、キーのないテーブルの論理的な意味は...
account amount
123 $10.00
...は（たとえば）...とまったく同じです...
account amount
123 $10.00
123 $10.00
123 $10.00
123 $10.00
実際にアカウントに 4 回支払われたことを知りたい場合は、...$10.00123
account amount count
123 $10.00 4
...そして{account, amount}キーを作成しますか？理論的には、既存の列をキーに入れてカウントを追加することで、キーなしテーブルをキー付きテーブルにいつでも変換できます。
しかし、実際には、特定の金額が何回支払われたかについてはあまり気にしません。支払いの順序や時間 (および最後に正しい金額が得られること) を気にします。では、それに基づいてキーを作成してみませんか?
それは一般的なやり方です、はい。はい、データの正規化の一部です。
ただし、データを適切に保存し、上位レイヤーがそのまま読み取れるようにするために、非正規化が必要になる場合があります。答えは NO です。特効薬ではありません。
インデックスを使用してクエリを強化し、DB を適切に設計して (利用可能な場合は適切な PK/FK を識別します)、アプリの制御とニーズを保持する適切な方法で正規化してください。