7

最近、非常に大きなデータベーステーブルを小さくて管理しやすいテーブルに分割しました。ほとんどの場合、作業に満足しており、データは適切に正規化されていると感じています。

ただし、これには1つの例外があります。問題のテーブルは、会社が販売している（ご想像のとおり）製品に関する情報を格納している製品データベースからのものです。情報の多くを2つのテーブルに分けました：ProductBaseとProductBasePackaging。

これらの表には、個々の製品ではなく、基本部品番号に関連する一連の情報が含まれています（各基本番号には複数の製品があります）。

ProductBaseなどのかなり一般的な情報と、材料、コンポーネントなどの構造に関する情報が含まれていMarketingCopyますKeywords。

そしてProductBasePackagingもちろん、パッケージに関するデータを保持しています。

データ操作用のアプリケーションを作成しているので、自分自身を推測し始めています。同じキー（基本部品番号）を使用する複数のテーブルを追跡する必要があるため、自分自身が困難になっているようです。それとも、それらをそのように分離し、それをさらに一歩進めて、構造を独自のテーブルに分離したのは正しいですか？

私はSQLの使用にかなり精通していますが、既存の大規模なデータベースを再構築することは言うまでもなく、実際にデータベース構造を設計する必要があったのはこれが初めてです。つまり、基本的に私が求めているのは、データの種類によって分離された同じキーを持つ複数のテーブルを用意するか、同じキーを使用して1つのテーブルから必要なものすべてを参照できる単一のテーブルにまとめる必要があるかどうかです。

申し訳ありませんが、それは読むことがたくさんあったことを知っています、それが理にかなっていることを願っています、そしてそれをやり遂げたすべての人に感謝します！

4

2 に答える 2

8

正規化は今のところa**の痛みのように見えるかもしれませんが、私を信じてください。長期的には、それを実行してよかったと思います。台所の流し台以外のすべてを含む正規化されていない「フラット」テーブルは、時間の経過とともに非常に管理しにくくなり、データの不整合が忍び寄ります。そして、それを知る前に、大量のがらくた-errrg-データがありません。もう意味があります！

はい、テーブルの結合は少し手間がかかる場合がありますが、特にデータを表示する場合は、これらのJOINを一度記述してから、すべてを保持する「仮想テーブル」として使用するのに役立つビューを必ず確認する必要があります。

データベースの正規化（最大で約3NF）は確かに良いこと（TM）です！私は常にそれを行うことをお勧めします、そしておそらくその時点で、パフォーマンスのニーズがそれを必要とするかもしれないいくつかの限定された非正規化を導入します-しかし非常に制御された方法でのみ、そしてあなたが実際に何かを再び非正規化しているというあなたの完全な理解と知識で。

于 2011-04-20T18:23:03.007 に答える
3

答えはそれが依存するということです。

これは、通常何をクエリするか、通常どのようにクエリするか、どのくらいの頻度でクエリするか、すべてのデータを保持するテーブルの大きさなどによって異なります。 正規化したく ない
場合の例としては、集計データまたは派生データを定期的にクエリする必要があり、コンパイルプロセスに「長い時間」がかかる場合があります。通常、データは正規化する必要があると思いますが。

そうは言っても、あなたが説明したのが分離であるのと同じくらい「正規化」であるかどうかはわかりません。正規化には、異なる列の重複データを削除することが含まれます。

パッケージングの例を見てみましょう...または何かにProductBasePackaging関連するいくつかのレコードを作成したように私には思えます。PartNumberProductBase

実際には、データを正規化する場合はProductBasePackaging、パッケージの種類ごとに1つの行しかありません。たとえば、1000種類の製品を出荷し、10種類の箱しか使用しない場合などです。 ProductBasePackaging10行あり、それぞれに一意のボックスに関する情報があります...次にProductBase、必要なボックスを次のように参照します。PackagingID

于 2011-04-20T18:19:36.327 に答える