2

それで、私は今、巨大なオンラインフォームを扱っています。視覚的にはさまざまなセクションに分かれていますが、それらは変化する傾向があります。約 300 のフィールドがあるので、それらを単一のテーブルに入れるのはばかげているように思えますが、それらを分離して、誰かがフィールドをフロント エンドの別のセクションに移動することを決定すると、データベースが混乱します。フィールドはフロント エンド セクションと一致しません。

私は基本的に質問しています:このようなものを正規化された方法で整理する最良の方法は何ですか?

4

4 に答える 4

2

フィールド名を別のテーブルに移動して、値テーブルで参照することができます。

例

field_id   | field_name
------------------------
1          | first_name
2          | last_name

次に、値から参照します。

value_id  | field_id   | value
--------------------------------
1         | 1          | John
2         | 2          | Doe
3         | 1          | Max
4         | 2          | Jefferson
于 2012-05-10T13:28:26.003 に答える
1

SQLデータベースを使用する場合は、上記のEntity-Attribute-Valueモデル（EAV）がおそらく良い答えです。また、いくつかの非正規化されたテーブルを一般的なデータまたは特殊なデータと混合することもできます。

ただし、別のオプションはドキュメントストアです。これは、MongoDBのようなデータストアに影響を与えたような問題のように聞こえます。MongoDBでは、すべてを巨大なjsonドキュメントとして保存するだけです。一部のレコードに一部のデータが不要であり、省略されている場合、まばらに配置されたワイドSQLデータベーステーブルのように「不良」とは見なされません。

于 2012-05-10T13:48:34.140 に答える
0

フィールドをグループ化できます。それらをコンポーネントとして分離すると、1 つのテーブルから複数のテーブルを作成できることに気付くでしょう。また、テーブルを分離することで、次のようにフォームを作成することはできません。

  • フィールドセットタグ
  • 複数のステップに分けます（最適なソリューションを考えます）
  • 前の入力後の各フォームに対する複数の ajax リクエスト
  • JavaScript ウィンドウの開閉で区切られたフォーム
于 2012-05-10T13:25:34.970 に答える
0

データベース設計、オブジェクト設計、およびフォーム設計は、3 つの非常に異なる要素です。データ間に 1 対 5 の関係がある場合は、データを正規化するために別のテーブルを用意する必要があります。ただし、すべてが 1 対 1 の関係である場合は、300 個すべてを同じテーブルに配置してもまったく問題ありません。それ自体に 300 の要素を持つ論理的または物理的な構造があるとは信じがたいと思います。しかし、それは可能です。何かの属性データに取り掛かり始めたら、乗り物について話しているとしましょう。車、トラック、セミ、オートバイ、自転車などについて話している可能性があります。これらのタイプの車両にはそれぞれ異なるプロパティがあり、データを正規化するために別々のテーブルで管理されます。それらの要素を別のページに移動してもあまり意味がありません。しかし、共通の属性を移動する可能性があります。たとえば、セクション 1 とセクション 4 で色について質問することはありません。ただし、セクションを分けて、メーカー、モデル、カスタム属性を説明する場合があります。

于 2012-05-10T13:49:38.130 に答える