6

CMSのユーザーモジュールに新しい機能を追加していて、障害にぶつかりました...または、道路の分岐点であると思います。何かに取り組む前に、stackoverflowから意見を聞きたかったのです。
基本的に、管理者が新しい「追加の」ユーザーフィールドを追加できるようにします。このフィールドは、ユーザーが登録時に入力したり、プロファイルを編集したり、他のモジュールで制御したりできます。この例としては、誕生日フィールド、自分自身の長い説明、またはユーザーがサイトで獲得したポイントなどがあります。言うまでもなく、保存されるデータはさまざまであり、大量のテキストから小さな整数値までさまざまです。さらに悪いことに、このデータを検索するオプションが必要です。

それが邪魔にならないように-これを行うための最良の方法は何でしょうか？今、私は次の列を持つテーブルを持つことに傾いています。

userid, refFieldID, varchar, tinyint, smallint, int, text, date, datetime, etc.

検索が大幅に高速化され、参照テーブル（フィールドの名前、検索可能かどうかなど、フィールドのすべてのデータを保持する）で、どの列を使用するかを参照できるので、これをお勧めします。そのフィールドのデータを保存します。

私に提案された他のアイデアと私は他のソリューションで使用されているのを見ました（vBulletinは1つですが、現在名前が私をエスケープしている他の人を見ました）、ユーザーID、参照ID、およびmedtextがあります分野。これを確実に言うにはMySQLについて十分な知識がありませんが、この方法では検索が遅くなり、オーバーヘッドが大きくなる可能性があります。

では、どの方法が「最良」でしょうか？私が見逃している別の方法はありますか？どちらの方法を使用する場合でも、検索は高速で、大規模ではなく（わずかなオーバーヘッドで十分です）、データに対して複雑なクエリを使用できるようにする必要があります。

4

2 に答える 2

3

Key-Valueテーブルがおそらく最良の解決策であることに同意します。私の最初の傾向は、vBulletinが行ったように、テキスト列を格納することです。ただし、データストアの機能を、レイアウトしたようにもう少し拡張可能で検索可能にする機能を追加したい場合は、次のことをお勧めします。

  • 任意のテキスト/バイナリストレージ用の1つのmedium/longtextまたはmedium/longblobフィールド（格納されているもの+文字列長の場合は3〜4バイトのオーバーヘッド）。ロングよりもミディアムを選択する唯一の理由は、保存できるものを2 ^ 32バイト（2 GB）ではなく2 ^ 24バイト（16.7 MB）に制限することです。
  • 1つの整数（4バイト）またはbigint（8バイト）
  • 1日時（8バイト）
  • おそらく、浮動小数点ストレージの場合は1フロートまたはダブル（4〜8バイト）

これらのフィールドを使用すると、ほぼすべてのタイプのデータをテーブルに格納できますが、テーブルの幅を拡大することなく**（varcharのように）、冗長なストレージ（tinyintやmediumintなど）を回避できます。ロングテキストフィールドに格納されているテキストは、フルテキストインデックスまたは通常の制限された長さのインデックス（例index longtext_storage(8)）を使用して合理的に検索できます。

** longtextなどのすべてのblob値は、メインテーブルから独立して格納されます。

于 2011-02-07T04:00:22.810 に答える
0

効果的な手法の1つは、この任意のデータをJSON、XML、YAMLなどの表記法でテキストとして保存することです。この決定は、データにアクセスする必要がある方法によって異なります。各ユーザーのユーザーデータの完全なチャンクのみを検索する場合は、理想的です。ユーザーデータの特定のフィールドでSQLクエリを実行する必要がある場合は、純粋なSQLまたはハイブリッドアプローチを使用する必要があります。

新しい、拡張性の高い「NoSQL」システムの多くは、JSONデータを好むようです（MongoDB、CouchDB、Project Voldemortなど）。それは素晴らしく簡潔であり、マップ（JSONオブジェクト）やリスト（JSON配列）を含む任意の複雑な構造を作成できます。

于 2011-02-07T04:02:10.913 に答える