0

アプリケーションのカスタムフィールド機能を構築しています。これにより、管理者は、サイトのニーズに応じてユーザーが入力できるカスタムプロファイルフィールドを追加できます。

スキーマは単純です

field_meta (store some metadata about the field)
================================================
id
type //type of field
field_name //name of the field in the fields table
render_data //Some data to use when rendering the form field

field
===================
id
name //Default field that can't be deleted
address //Default field that can't be deleted
customfield_1
customfield_2

このfield_metaテーブルは、フォームフィールドをレンダリングできるように、フィールドのメタデータを格納するために使用されます。

各フィールドは、fieldテーブルの新しい列に格納されます。

問題：使いやすさのために、また列名に予約語を選択したり、英語以外の単語を使用したりする必要がないように、列名に名前を選択するようにユーザーに依頼することはありません。

私は現在、フィールドタイプ（アプリケーションにはかなりの数のタイプ（電子メール、Webサイト、テキスト、段落テキストなど）があります）で列名を呼び出し、番号を追加することを検討しています。いくつかの例：

  • Email_1
  • 文1
  • Text_2
  • Text_3
  • Email_2
  • 等

ただし、このアプローチの問題は、列名を思い付くのにかなりの作業が必要になることです。すべての列を取得し、作成しているのと同じ列タイプの列を選択し、最大数を解析してから、列を作成する必要があります。

これを行うためのより良い戦略はありますか？それとも、これらの問題を排除する列に名前を付けるまったく異なる方法ですか？

4

2 に答える 2

0

私は元のアプローチを採用することにしました。つまり、基本的に、タイプと増分番号で構成される列名を作成します。

  • メール_1
  • 文1
  • テキスト_2
  • テキスト_3

名前の生成にはかなりの労力がかかりますが、これはプロファイル フィールドの作成時にのみ行われるため、パフォーマンス ヒットはその間にのみ発生します。

于 2012-06-15T01:20:09.343 に答える
0

列を動的に追加しようとしないでください。これは遅い (そして適切な形式ではない) メソッドです。

代わりに、余分な列を新しいテーブルに格納し、それぞれに独自の ID を付けます。次に、ユーザー ID、追加の列 ID、およびそのユーザーの属性情報を格納する別のテーブルを作成します。これは、実際にそうする必要なく、新しい列を追加することを模倣します。

編集：確かにEAVのように聞こえます。スキーマ:
Attributes{id:int, name:string}
Users{id:int, name:string, (他に必要なものは…)}
Users_attributes{Attribute_id:int, User_id:int, Attribute_info:string}

次に、新しい属性を Attributes (増分 ID を使用) に入力し、新しいユーザー情報を適切な User_id と Attribute_id を使用して User_attributes に入力します。

于 2012-05-23T04:33:51.553 に答える