2012-01-31 16 views
1

私は以下の2つの理由から、SQLテーブル構造にあまり満足していません。私はすべての項目を一覧表示していますことを好きではないSQLテーブル構造のフィードバック

  1. は、1020バイトのvarchar型の変数の順序(orders.itemOrderIds)に含まれています。私は、ID番号の束を保持するよりエレガントな方法があるように感じる。

  2. 私は、項目テーブルのitemDescription変数から自分のJavaコード内の項目(基本的な項目)に関する情報を抽出することに頼っています。

誰もがこれらの状況に対処する最善の方法についてアドバイスしていますか?このWebサイトでは、Javaコードでテーブルを生成することは問題ありません。つまり、私のJavaコードはorderI(orderId)_itemsというテーブルを作成し、orderIdでその注文に含まれるすべてのアイテムを保持します。これはこれを行う最善の方法ですか?

CREATE TABLE IF NOT EXISTS customers 
(
id INT AUTO_INCREMENT, 
name VARCHAR(255) NOT NULL, 
email VARCHAR(255) NOT NULL, 
company VARCHAR(255) NOT NULL, 
address1 VARCHAR(255) NOT NULL, 
address2 VARCHAR(255), 
city VARCHAR(255) NOT NULL, 
province_state VARCHAR(255) NOT NULL, 
country VARCHAR(255) NOT NULL, 
zip VARCHAR(255), 
telephone VARCHAR(255), 
PRIMARY KEY(id) 
) ENGINE = INNODB; 

CREATE TABLE IF NOT EXISTS orders 
(
id INT AUTO_INCREMENT, 
customerId INT NOT NULL, 
orderNum VARCHAR(255) NOT NULL, 
itemOrderIds VARCHAR(1020) NOT NULL, 
regName VARCHAR(255) NOT NULL, 
regCompany VARCHAR(255) NOT NULL, 
regEmail VARCHAR(255) NOT NULL, 
orderTime DATETIME NOT NULL, 
FOREIGN KEY(customerId) REFERENCES customers(id), 
PRIMARY KEY(id) 
) ENGINE = INNODB; 

CREATE TABLE IF NOT EXISTS items 
(
itemNum VARCHAR(255) UNIQUE, 
itemName VARCHAR(255), 
itemTypeId SMALLINT NOT NULL, 
--itemDescription must hold all information needed to generate license keys in format 
-- Field_Name1: Field_Value1, Field_Name2: Field_Value2, ..... 
-- Field names are platform, version, (choose one: port, voiceName) 
itemDescription VARCHAR(1020), 
FOREIGN KEY(itemTypeId) REFERENCES item_types(id) ON DELETE CASCADE, 
PRIMARY KEY(id) 
) ENGINE = INNODB; 

CREATE TABLE IF NOT EXISTS item_types 
(
id SMALLINT AUTO_INCREMENT, 
itemType VARCHAR(255) UNIQUE NOT NULL, 
PRIMARY KEY(id) 
) ENGINE = INNODB; 

CREATE TABLE IF NOT EXISTS item_orders 
(
id INT AUTO_INCREMENT, 
itemNum VARCHAR(255) NOT NULL, 
licenseKey VARCHAR(255) NOT NULL, 
FOREIGN KEY(itemNum) REFERENCES items(itemNum), 
PRIMARY KEY(id) 
) ENGINE = INNODB; 

編集:

CREATE TABLE IF NOT EXISTS Order_Items 
(
orderId INT NOT NULL, 
itemOrderId INT NOT NULL, 
PRIMARY KEY(orderId, itemOrderId) 
) ENGINE = INNODB; 
+0

ほとんどの属性で 'VARCHAR(255)'を使用すると、smellyになります。 – onedaywhen

+0

あなたはそれについてもっと言ってもらえますか?私は初心者のソフトウェア開発者(わずか1年間の経験)ですので、アドバイスをいただければ幸いです。 – thatidiotguy

+0

'orderNum'の値は255文字にはならないと思います。彼らはおそらく長さがまったく変わらないでしょう。値が実際には常に10文字であれば 'CHAR(10)'が適切です:これはデータの重要な特性をユーザに示し、あなたは最大長の 'free for'をチェックします。これはmySQLにとって特に重要です'CHECK'制約のサポートが欠けているからです。臭いに関しては、 'VARCHAR(255)'を使用することは、問題の企業に関する特定の知識を持つ人がデータモデルを設計していないことを示唆しています。 HTH。 – onedaywhen

答えて

3

はい、あなたはむしろ、varchar型のフィールドにオーダーIDのすべてを非正規化よりも、(私は通常、名前の最初の親オブジェクトを置く)OrderItem交差テーブルを必要としています。このようにフィールドを正しく索引付けする方法はなく、更新が非常に困難になります。

database normalizationを読んでください。これは最初に見つかる最初のタイプの例です。

+0

私はこのようなテーブルを持っているべきだと言っています。 – thatidiotguy

1

これを行う最善の方法は、すべてのデータ構造を少なくとも3NFに正規化することです。また、Ordersテーブルへの参照を保持する別のテーブル内の注文アイテムのより良好な店舗リスト - 今のところとして

Database Normalization

0

オーダー明細テーブル(結合テーブルではありません)が必要です。どうして?注文情報は特定の日付に固有のものです。その日の情報を保存する必要があります。したがって、注文の詳細には、通常、商品番号、商品の名前、価格(価格を含むことが重要です.2年後の価格ではなく、注文が販売された時点で価格が必要です)、オーダーテーブルには、配送先の住所、時間の経過とともに変化する顧客の名前などの詳細も含める必要があります。

私はまた、顧客テーブルを壊します。顧客は通常、複数のアドレス、電話番号、電子メールを持つことができ、それぞれ別個の関連テーブルでなければなりません。

+0

プログラムは資金調達情報の詳細を担当していません。注文されたものを記録するだけで、顧客がライセンスキーを失った場合、後でそれを検索することができます。ライセンスキーは、発注時に提供された情報に依存し、出荷先アドレスは現在のところありません。私のプログラムのもう一つは、財政を扱うものであり、そうでないものです。 – thatidiotguy

関連する問題