3

私はデータベース設計にまったく慣れていないので、ベスト プラクティスについていくつか質問があり、本当に学びたいと思っています。私はデータベース スキーマを設計しています。要件をよく理解していますが、今はそれを白黒にする問題です。

この疑似データベース レイアウトには、顧客のテーブル、注文のテーブル、製品のテーブルがあります。

TBL_PRODUCTS:
ID
説明
詳細

TBL_CUSTOMER:
ID
名
アドレス

TBL_ORDER:
ID
TBL_CUSTOMER.ID
prod1
prod2
prod3
など

各「注文」には 1 人の顧客しかいませんが、「製品」はいくつでも持つことができます。

問題は、私の場合、特定の注文の製品が任意の量 (1 回の注文で数百) になる可能性があることです。さらに、注文の各製品には「数量」以上のものが必要ですが、ページにまたがる値を持つことができます。特定の注文の特定の製品のテキストの。私の質問は、その情報をどのように保存できますか?

可変長配列を単一のフィールド値として保存できないと仮定すると、他のオプションは、何らかの方法で区切られ、アプリケーションでコードによって分割される文字列を持つことです。注文には、たとえば 100 個の製品があり、各製品には小さな int のみ、または 5000 文字またはフリー テキスト (またはその間の任意のもの) があり、その注文にのみ固有です。

その上、各注文には独自の監査証跡が必要です。これは、注文の存続期間中に多くのことが発生する可能性があるためです。監査証跡には通常の情報 (ユーザー、時刻/日付、アクション) が含まれ、任意の長さにすることができます。特定の注文の監査証跡を、注文が作成されたときに作成される独自のテーブル (非常に長くなる可能性があるため) に保存しますか?

データベース設計のテクニックについてもっと学べる場所はありますか?

4

6 に答える 6

8

最も一般的な方法は、注文項目を別のテーブルに格納することです。

TBL_ORDER:
ID
TBL_CUSTOMER.ID

TBL_ORDER_ITEM:
ID
TBL_ORDER.ID
TBL_PRODUCTS.ID
Quantity
UniqueDetails

同じことが注文監査証跡にも当てはまります。次のような新しいテーブルにすることができます

TBL_ORDER_AUDIT:
ID
TBL_ORDER.ID
AuditDetails
于 2008-12-24T04:30:50.863 に答える
4

まずはGoogleの第三正規形。ほとんどの場合、テーブルは 3NF である必要がありますが、パフォーマンスや使いやすさのためにこれが当てはまらない場合があり、実際にそれを教えてくれるのは経験だけです。

あなたが持っているものは正規化されていません。多対多の関係を実装するには、「結合テーブル」が必要です。

TBL_ORDER:
ID
TBL_CUSTOMER.ID

TBL_ORDER_PRODUCT_JOIN:
ID
TBL_ORDER.ID
TBL_Product.ID
数量

TBL_ORDER_AUDIT:
ID
TBL_ORDER.ID
Audit_Details

于 2008-12-24T04:30:52.660 に答える
2

データベーススキーマの設計方法に関するリファレンスではありませんが、 DatabaseAnswers.orgのスキーマライブラリをよく使用します。すでに荒削りされたものが必要な場合は、飛び降りるのに適した場所です。完璧ではなく、ニーズに合わせて変更する必要がありますが、500を超える場所があります。

于 2008-12-29T14:20:13.730 に答える
2

Ordersテーブルの ID 列の基本的な従来の名前(ORDER は SQL のキーワードであるため、複数形) は「Order Number」ですが、正確なスペルはさまざまです (OrderNum、OrderNumber、Order_Num、OrderNo など)。

TBL_ プレフィックスは不要です。たとえば、TBL_ORDER テーブルで使用される TBL_CUSTOMER.ID 列名のように、常にテーブルを意味するとは限らないため、二重に不要です。また、一般に、「。」を使用するのは悪い考えです。列名の途中。その名前は、二重引用符 (標準 SQL およびほとんどの DBMS) または角括弧 (MS SQL Server; Sybase については不明) で囲み、常に区切り識別子として扱う必要があります。

Joe Celko は、列の命名などについて多くのことを述べています。彼の言うことすべてに同意するわけではありませんが、簡単に検索できます。Fabian Pascal の「データベース管理における実際の問題」も参照してください。

他の回答は、「注文アイテム」テーブルが必要であることを示唆しています-それらは正しいです。あなたがやる。答えは、そこに量を保存することについても話しました。量以上のものが必要になることを忘れないでください。たとえば、注文時の価格が必要になります。多くのシステムでは、割引、税金、およびその他の詳細を処理する必要がある場合もあります。また、複雑なアイテム (飛行機など) の場合、注文の「アイテム」は 1 つだけかもしれませんが、記録される下位の詳細は膨大な数になります。

于 2008-12-24T05:30:21.370 に答える
1

データベース要件分析のためのエンティティ関係 (ER) モデリングについて学習します。

リレーショナル データベースの設計と、テーブルの全体的な論理設計のためのリレーショナル データ モデリングについて学びます。データの正規化はこの記事の重要な部分ですが、学ぶべきことがすべてではありません。リレーショナル データベースの設計は、メイン ストリームの DBMS 製品内ではほとんど DBMS に依存しません。

物理データベースの設計について学びます。パフォーマンスを考慮した設計の最初の段階として、インデックスの設計について学びます。一部のインデックス設計は DBMS に依存しませんが、物理的な設計は、詳細になるほど DBMS の特別な機能にますます依存するようになります。これには、使用する DBMS に合わせて特別に調整された書籍が必要になる場合があります。

最初のデータベースを設計して構築する前に、上記の学習をすべて行う必要はありません。しかし、あなたが知らないことはあなたを傷つけます。他のスキルと同様に、やればやるほど上達します。そして、他の人がすでに知っていることを学ぶことは、試行錯誤によって学ぶよりもはるかに安価です.

于 2008-12-29T14:01:13.410 に答える
-2

Rails を使用した Agile Web Development を見てください。ActiveRecord (Rails での同じ名前のデザイン パターンの実装) に関する優れたセクションがあり、Rails を使用したことがない場合でも、これらのタイプの関係を非常にうまく説明しています。ここにも良いオンラインチュートリアルがあります。

于 2008-12-24T04:47:38.523 に答える