問題タブ [database-normalization]

データベース構造を作成するとき、従うべき適切なガイドライン、またはデータベースをどこまで正規化する必要があるかを判断するための適切な方法は何ですか? 正規化されていないデータベースを作成し、プロジェクトの進行に合わせて分割する必要がありますか? 完全に正規化して作成し、パフォーマンスのために必要に応じてテーブルを結合する必要がありますか?

それぞれ 30 を超えるフィールドを持つ複数のテーブルを持つ新しいアプリ用のデータベースを計画している同僚がいます。これは過剰ですか？多分私は理解するのに十分なほど積極的ではありません。

編集：また、多くのフィールドはオプションタイプのものです（リクエストフォームのように、ウィジェットを黄色または緑色にしたい場合、列挙型の「色」のフィールドがあります）。これらは時間の経過とともに追加または削除される可能性が非常に高いです。私は実際にデータベースの設計を行ったことがなく、自分でそれを避けようとしているので、完全に愚かであるかもしれませんが、これを行うためのより良い方法は確かにあります??

データベース担当者が正規化について話し続けるのはなぜですか?

それは何ですか？それはどのように役立ちますか？

データベース以外にも適用されますか?

ノーマライゼーションは、美的快楽を含む多くの本質的で望ましい特性につながります。その上、それは理論的にも「正しい」です。このコンテキストでは、パフォーマンスを達成するための妥協、修正として非正規化が適用されます。データベースが非正規化される可能性があるのは、パフォーマンス以外の理由がありますか?

私はこれが頻繁に出てくることに気づきましたが、それにアプローチする最善の方法がわかりません。

私が抱えている問題は、ルックアップ テーブルに外部キーを使用するか、それを要求するテーブルで直接ルックアップ テーブルの値を使用して、ルックアップ テーブルの関係を完全に回避するかを決定する方法です。

注意点：

• 2 番目の方法では、ルックアップ テーブルでデータが変更された場合、データを参照するすべてのレコードを一括更新する必要があります。

• これは、多数のルックアップ テーブルを参照する多数の列を持つテーブルに重点を置いています。したがって、多数の外部キーは、テーブルをクエリするたびに多数の結合を意味します。

• このデータは、ルックアップ テーブルから取得されるドロップ ダウン リストから取得されます。リロード時にデータを一致させるには、値が既存のリストにある必要があります (最初のポイントに関連する)。

ここでのベスト プラクティス、または考慮すべき重要なポイントはありますか?

私はこれらのテーブルを持っています：

CreatedByIDの外部キーですEmployees。ほぼすべてのページの読み込みに対して実行されるクエリがあります。

3つの結合を削除するために、冗長なOfficeID列を追加するのは悪い習慣ですか？Projectsまたは、次のことを行う必要があります。

アプリケーションプログラミングでは、「最初にベストプラクティスで記述し、後で最適化する」のですが、データベース管理者は常に結合のコストについて警告しています。

次のように動作するツールについて学ぶことに興味があります。

データベース スキーマといくつかのデータが与えられた場合、スキーマが特定の正規形で構造化されている可能性が高いかどうかを示し、さらに正規化を行うためにスキーマをどのように分解できるかを示します。

基本的には、データベース スキーマ設計のための静的分析ツールです。

他の静的分析ツールと同様に、そのようなデータベース ツールは完璧な結果を生成する必要はなく (そのような「完璧な」ツールが計算上実行可能であるとは思えません)、すべてのデータベース システム、フリー/オープン ソース、またはその他のあらゆるものに適用できます。ツールはスタンドアロンである必要はありません。洗練された IDE 機能としてバンドルされる可能性があります。そこに何があるのか​​ 疑問に思っています。

最初の正規形は、行の順序は重要ではないことを示しています。これは、キーの一部として日付が含まれるテーブルが1NFではないことを意味しますか？たとえば、日付/時刻がPKの一部であるティッカー価格の表を考えてみます。この場合、データを日付順に並べ、上位1行を選択することで、最終価格を取得します。これは、1NFを満たすために、テーブルを次のように分割する必要があることを意味します：1）TickerCurrentPrice（ティッカーごとに1行）2）TickerHistoricalPriceありがとう