1

次の表を使用することは、これまでのベスト プラクティスまたは推奨事項ですか? 

 id, uid, fieldname, fieldvalue
    4, 12, gender, male
    5, 12, age, 21-30
    6, 12, location, 5
    7, 13, gender, female
    8, 13, age, 31-40
    9, 13, location, 5
    10, 14, gender, female
    11, 14, age, 31-40
    12, 14, location, 6
    13, 15, gender, male
    14, 15, age, 21-30
    15, 15, location, 7

これは正規化されておらず、フィールドのデータ型を指定できません。

次のほうがいいのではないでしょうか

id, uid, gender, age, location
4, 12, male, 21-30, 5
5, 13, female, 31-40, 5
6, 14, female, 31-40, 6
7, 15, male, 21-30, 7

データベースにそのようなテーブルがあることを正当化できるかどうかを知りたいのですが、最初の方法は (データベースを変更する代わりに) フィールドを追加する方が簡単で、おそらくすべての null 値を削除することを知っています.

ただし、データ型を指定することはできず、データを使用するたびに文字列から変換する必要があります。

では、最初の表がベスト プラクティスまたはソリューションと見なされるシナリオはありますか?

4

3 に答える 3

0

その方法を使用するシステムで作業すると、正気を失います。基本的なタスクを実行するために必要なクエリの複雑さは恐ろしく、パフォーマンスは悪夢のようです。

これはある男性の経験です: https://www.simple-talk.com/opinion/opinion-pieces/bad-carma/

于 2013-04-30T21:28:46.373 に答える
0

あなたが説明する最初のタイプの構造は、属性が事前に知られていないアプリケーションでは非常に一般的です。たとえば、ユーザーが連絡先に関する詳細を保存できるシステムを開発している場合があります。保存される詳細の一部は知っているかもしれませんが、他の詳細は知らないかもしれません。そのため、ユーザーが連絡先のカスタム属性を定義できるようにすることができます。

もちろん、このタイプの設計は、データベースに適用されたチェックを失い、アプリケーションに適用されたチェックに依存しなければならないことを意味します。それは短所ですが、柔軟性が本当に必要な場合は、契約を破る必要はありません.

于 2013-04-26T16:19:55.110 に答える