DBデザイン - 複数のテキストフィールド

私はいくつかの言語で製品とその説明を含むテーブルを持っています。今のところ、テーブルの構造は次のようになります

tblProducts

productId INT PK AI
productDesc_en VARCHAR
productDesc_de VARCHAR
productDesc_it VARCHAR

等々。 enは英語、deはドイツ語

彼の言語設定に従う訪問者は彼の言語に関する記述を見る。

ちょうど不思議ですが、代わりにこのようなデータを格納することに何らかの利点がありますか?

tblProducts

productId INT PK AI

tblProductDesc_en

descId INT PK AI
tblProducts_productId INT FK
description VARCHAR

tblProductDesc_de

descId INT PK AI
tblProducts_productId INT FK
description VARCHAR

tblProductDesc_it

descId INT PK AI
tblProducts_productId INT FK
description VARCHAR

この解決策で私が見るプロ

  1. DBの観点から維持しやすくする
  2. DBレコードからオブジェクトをインスタンス化するときに使用されるメモリが少なくなりました(必須の言語 オブジェクト内に格納されます)

con(s):

  1. JOINを使用して、パフォーマンスを上回る可能性のある必要なデータを取得する必要があります。
  2. クラス内でより複雑なgetterとsetter

他に何か?

ありがとうございました!

0
なぜ tblProductDesc が1つだけでなく、 tblProductDesc_lang の列を追加するのはなぜですか?各言語の新しい行を保存しますか?
追加された 著者 Jared Farrish,
あなたのソリューションでは、あなたの質問にあるものを参照していますか?同じ正確な列を持つ複数の表を持つことについて話していますが、唯一の違いは行(属性)の属性です。あなたは空の行を持っている必要はありません。説明を保存するときは、使用可能な言語ごとに行を追加します。
追加された 著者 Jared Farrish,
@ JaredFarrish、それは2番目の解決策との違いは何ですか?私はまだ正しい結果を取得するためにjoinを使用しなければなりません。また、私はそこに特定の言語の記述がない空の列をたくさん格納する必要があります。
追加された 著者 paulus,

2 答え

私は、新しい言語が追加されたときに、より安定したdbスキーマを提供する、正規化に非常に近い良い解決策になると思う。

それは次のようになります:

CREATE TABLE `language` (
  `prodID`  INT UNSIGNED NOT NULL  ,
  `desc` varchar(30) null  ,
  `lang`  char(2) NOT NULL,
  PRIMARY KEY  (`prodID`,`lang`),
  CONSTRAINT `fk0` FOREIGN KEY (`prodID`)
        REFERENCES `product` (`prodID`)
        ON DELETE CASCADE
) ENGINE=InnoDB ROW_FORMAT=COMPACT;

外部キーは、製品が削除されたときに完全性を提供し、製品が存在する場合にのみ挿入を許可します。

複合主キーでは、言語と商品の説明が1回だけ保存されます。

従属性に関しては、プライマリキーはプライマリキーの両方の部分に依存するため、このプライマリキーはうまく見えます。

プライマリキーと外部キーの一部と同じフィールドを持っています。プライマリキーのこの部分を借りるようなものです。

==========編集1(上記の変更はありません)============== descフィールドで NullNull に置き換えます。次に、商品が存在し、説明がない場合、これは利用可能な説明がないことを意味します。上記のnull descを許可する理由はないというのが私の意見です。

2
追加された

あなたの既存の状況の最大の欠点は、言語を追加する必要がある場合です。現在のソリューションの変更は、言語が分離されている場合よりも、より広範で脆弱になる可能性があります。

あなたの2つの提案の中間にあり、提案されたソリューションの短所の影響を軽減する代替ソリューションがあります。これは、商品説明にデフォルトとして1つの言語を使用し、別の表に代替言語を使用することです。これは、大多数のユーザーがデータベースにアクセスすることを前提としています。

0
追加された
あなたのソリューションで - これは、コンストラクタメソッド内の記述を取得していることを前提としていますか?次に、記述が言語と一致しない場合は、別のメソッドを呼び出して正しい記述を取得するか、コンストラクタの実行中に言語を検出するための動的クエリを作成する必要があります。私は恐れている、これはより複雑になります。私が2番目のアプローチで見られる別のプロは、コンストラクタからの記述を得る必要はありません(私は通常、コンストラクタにできるだけ少ない引数を与えようとしますが)言語に応じて別のメソッドから記述を取得することです。
追加された 著者 paulus,
PHP - 日本のコミュニティ [ja]
PHP - 日本のコミュニティ [ja]
4 参加者の

このグループではPHPについて話します。 パートナー:kotaeta.com