16

Web アプリケーションのユーザー固有の設定を保存する最良の方法は何だろうと思っていました。ユーザーが持っているかもしれない好みだけです。私は2つのオプションを考えました：

  1. ユーザー テーブル- ユーザー用のテーブルを作成します。「設定」と呼ばれる列を作成し、そこにシリアル化されたデータをキー => 値のペアで保存します

  2. 設定テーブル- user_id 列を持つ settings という別のテーブルを用意します。同じように設定を保存します

任意の入力をいただければ幸いです。ありがとう ：）！

--

編集：追加するために、シリアル化/jsonまたはデータに入れるデータを何もしなかった場合、設定ごとに列が必要になります。

4

6 に答える 6

29

すべてのユーザーに対して常に設定されるものについては、通常の正規化に従って、テーブルに保持する傾向があります。オプションの構成に関しては、次のテーブル構造が好きです。Users

TABLE Users:
  id INT AI
  name VARCHAR
  ...

TABLE User_Settings
  user_id INT PK,FK
  name VARCHAR PK
  type BOOL
  value_int INT NULL
  value_str VARCHAR NULL

WhereUser_Settings.typeは、整数フィールドまたは文字列フィールドのどちらを参照するかを指定します。

すなわち:

INSERT INTO Users (id, name) VALUES (1, 'Sammitch');
INSERT INTO User_Settings (user_id, name, type, value_int) VALUES (1, 'level', 1, 75);
INSERT INTO User_Settings (user_id, name, type, value_str) VALUES (1, 'lang', 0, 'en');

また、INSERT/UPDATE の問題については、次のようになります。

INSERT INTO User_Settings (user_id, name, type, value_str) VALUES (1, 'lang', 0, 'fr')
  ON DUPLICATE KEY UPDATE value_str='fr';

また、他のほとんどの人が言っているように、設定をシリアル化して保存することは、次の理由から特に良い考えではありません。

  1. クエリで単一の値を取得することはできません。シリアル化された文字列全体を取得し、逆シリアル化し、不要なデータを破棄する必要があります。
  2. 壊れやすく、元に戻すのは困難です。
  3. 生のクエリを書くのは大変です。つまり、特定の設定をグローバルに修正します。
  4. 基本的に表形式のデータを 1 つのテーブル フィールドに格納しています。

2016 年 9 月回顧録編集:

それまでの間、オプションの設定を保存する最善の方法と、上で定義した一般的なテーブル構造について、人々といくつかの議論をしました。

そのテーブル構造は完全に悪いわけではありませんが、まったく良いわけでもありません。それは、悪い状況を最大限に活用しようとしています。オプション設定のシリアル化は、次の設定に対応できる限り機能します。

  1. すべてが一度にロードされ、ピッキングや選択はありません。
  2. インデックス可能、検索可能、またはまとめて簡単に変更できない。

次に、シリアル化された [例: JSON] 形式の設定を含む表のようなフィールドを追加することを検討してoptional_settingsください。Users上記をトレードオフしますが、より簡単なアプローチであり、より複雑な設定を保存できます。

また、ストレージのような LOB タイプを使用する場合、TEXT少なくとも MySQL では、データは必ずしも「行に」格納されるとは限りません。

とにかく、アプリケーションの要件と制約が何であるかを判断し、その情報に基づいて最適な選択を行うのはあなた次第です。

于 2013-01-02T16:21:40.747 に答える
2

それはすべて、データベースの設定とスキーマに依存します。あなたが何をしても、あなたの提案1に従ってデータをシリアライズしないことをお勧めします。データをシリアライズすると、それに対してクエリを書くことができなくなり、シリアライズしたのと同じ言語を使用してデシリアライズする必要があります(または、その言語）。

私がお勧めするオプションは、列ごとに 1 つの設定をユーザー テーブル内に配置することです。これの欠点は、アプリケーションに新しい設定を追加するときに、新しい列を追加するために DDL スクリプトを作成する必要があることです。これの (非常に良い) 利点の 1 つは、各設定が独自のデータ型を持つことができることです。この設定がオプションの場合、これにはストレージのペナルティもあります。

別のオプションは、あなたが提案したように、設定値の3番目の列を持つ（user_id、setting_name）の主キーを持つ設定テーブルを使用することです。このソリューションは、すべての設定が同じデータ型であることを前提としています。新しい設定を追加するために DDL スクリプトを記述する必要はありません。新しいキー名を使用するだけです。

于 2013-01-02T16:08:03.330 に答える
1

それは常に同じ問題です: どのくらいの頻度でそれらのデータを変更する必要がありますか? 私の意見では、別のテーブルを持つことは、アプリケーションのさまざまな側面を分離するため、常に良い解決策です。

ユーザーが設定を変更するたびに、すべてのデータをシリアル化してテーブルpreferencesに保存する必要があるため、列を持つことはお勧めできません。本当にすべてを に保存したい場合は、設定を異なる列に分割する必要があります。usersupdateusers

于 2013-01-02T16:07:42.060 に答える
0

これは現在の状況には適切ではないかもしれませんが、NoSQLデータベース（Mongoなど）はこれに最適です。たとえば、このmongoデータベースでは、各ユーザーオブジェクトが実際には異なるプロパティを持つ可能性があり、それでもそれらを検索できます。

とは言うものの、あなたがいる状況については、過去に私はここで他の答えが示唆していることに従い、別の表を持っていました。これは2つの方法で行うことができます。列を変更する方が快適な別のテーブルを用意し、それに対して結合します。または、次のような個別のテーブルを持つ、より単純なソリューション

ユーザー、パラメーター、値。

次に、各ユーザーは異なる追加の値を持つことができます。

最適なアプローチは、必要なパフォーマンスなどによって異なります。

于 2013-01-02T16:14:00.423 に答える
0

2 番目のオプションですが、設定を個別に保存するように変更されています。シリアル化されたデータをフィールドに保存しないでください。この場合は悪い習慣です。

これを考えてみてください:あなたはそれを持っていて、そこにユーザーの国またはニュースレターに登録されているかどうかを保存します. 後で..ロシア出身の人数を知る必要があります。職業はなんですか？それらを1つずつ取り、デコードしてカウンターを増やしますか？(または、2 番目の方法を使用して、単純な SELECT COUNT(id) クエリを実行するだけですか?)

于 2013-01-02T16:06:42.920 に答える
0

後で簡単にアクセスできるようにするため、設定テーブルを使用します。1 つの列で名前と値のペアを作成しようとすると、後でデータにアクセスするクエリを設計しようとして問題が発生する可能性があります。

于 2013-01-02T16:07:04.233 に答える