主キーがないテーブルを持つデータベースを継承しました。これはOLTPデータベースです。問題のテーブルの1つには最大300kのレコードがあり、プライマリキーは実装されていませんが、スキーマの残りの部分を調べると、1つの列がプライマリキーとして使用されている、つまり同じ名前の別のテーブルに複製されていることがわかります。すなわち。これは「行末」テーブルではありません
このデータベースもFKを実装していません。
私の質問は-テーブル（そのことについてはOracleで）が主キーを持たない正当な理由はありますか？
ほとんどの場合、PK は必須だと思います。理由はたくさんありますが、そのうちのいくつかを扱います。
PK なしでテーブルを作成するケースはほとんどありません (ログ用のテーブルなど)。
Oracle に固有のものではありませんが、 mysqlがダム (発電) プロジェクト用に高度にカスタマイズされたユースケースの 1 つについて読んだことを思い出します。センサーからの入力データは、毎秒 100 ～ 1000 程度でした。彼らは各レコードにタイムスタンプを使用していたので、主キーは必要ありませんでした (ここの別の回答で言及されているログ/ロギングのように)。
したがって、正当な理由は次のとおりです。
uniqueただし、すべてのフィールドを網羅するインデックスが必要です。悪い理由は無限にあります:-)
実際に主キーの欠如の原因となる最も頻繁な悪い理由は、 DB の経験がほとんどまたはまったくなく、アプリケーション内のすべてのデータ制約を処理したい (または処理すべきだと考えている) アプリケーション/コード開発者によって DB が設計されている場合です。 .
正当な理由は？私は「いいえ」と言うでしょう--私はデータベースの男です--しかし、データベースを愚かなデータストアとして使用することを主張する場所があります。通常は、アプリケーション コードにすべての整合性「制約」を実装します。
アプリケーション コードに整合性制約を入れることは、通常、パフォーマンスを向上させるために行われるわけではありません。実際、既知のすべての制約を適用する 1 つのデータベースを構築し、機能的に同一の制約をアプリケーション コードのみに適用して別のデータベースを構築した場合、最初のデータベースはほぼ確実に 2 番目のデータベースの周りでリングを実行します。
代わりに、アプリケーション レベルの制約は通常、柔軟性を高めることを望んでいます。(そして、その過程で、通常、既知の制約のいくつかが削除され、パフォーマンスが向上するようです。) だらしないデータを一括ロードするために特定の制約を適用することが不便になった場合、アプリケーション プログラマーはアプリケーションを回避できます。 -レベルの制約を少しの間変更してから、都合のよいときにデータをクリーンアップします。
私はデータベースの専門家ではありませんが、Oracle アプリケーション部門で働いていた友人との会話を覚えています。これは緊急事態に対処するために行われたと私に言った。生成されたレポートに問題があり、行を追加することで修正できる場合、データベース レベルの制約が邪魔になることがよくあります。彼らは通常、データベースではなくアプリケーションに一意の主キーなどを実装しました。非効率的でしたが、彼らにとっては十分であり、災害復旧シナリオの場合にははるかに管理しやすくなりました.
列のサブセットに一意性を適用するには、主キーが必要です (個々の行を参照する必要がある場合に役立ちます)。また、インデックスが関連付けられているため、特定のクエリが高速化されます。
そのインデックスまたはその一意性制約が必要ない場合は、主キーは必要ない可能性があります (インデックスは解放されません)。
頭に浮かぶ例は、一部のデータを記録するだけのログ テーブルです (個々のレコードに対して更新またはクエリされることはありません)。
インデックス付きのテーブルに挿入するときはわずかなオーバーヘッドがあり、主キーがある場合はインデックスが必要です。もちろん、欠点は、行を見つけるのに非常にコストがかかることです。