2011-02-22 9 views
0

私は簡単なPHP Webアプリケーションを持っています。ユーザーのパブリックプロファイルから特定の詳細を隠すオプションを追加する必要があります。データベースは次のようなものです:プロフィールの詳細を非表示にする。 PHPは良い選択ですか?

id  username phone  email 
1  foo1  888-888 [email protected] 
2  foo2  999-999 [email protected] 
3  foo3  111-111 [email protected] 

私は2つの選択肢があります。まず、別のテーブルを持ち、idを参照のための外部キーとして使用します。同様に

fkeyID  disp_phone  disp_email 
1   0    0 
2   0    1 
3   1    1 

ここで、1は真であり、0は偽である。次に、2つのテーブルでSQL結合を使用して、電話/電子メールを表示するかどうかを調べます。

第2のオプションは、ユーザーがパブリックビューを禁止したい場合に、$のようなフラグ値の前に付加することです。次に、環境設定を表示または保存する前に、単純なPHPチェックを使用します。 Like:

id  username phone  email 
1  foo1  $888-888 [email protected] 
2  foo2  $999-999 [email protected] 
3  foo3  111-111 [email protected] 

スペースと複雑さの点で、どちらが良い選択肢であるかを教えてください。

+3

:: 'id'、' username'、 'phone'、' phone_disp'、 'email'、と' email_disp'

は次にようにテストします。これにより、データと可視性の設定が一緒に保持されます(ただし、1-1解決策と同じです)。 – jensgram

+0

単一の 'SET SET( 'phone'、 'email')'フィールドを追加するのはどうですか? – binaryLV

+0

@binaryLVあなたはあなたの解決策を詳しく教えていただけますか? – hiprakhar

答えて

0

idfKeyIDが両方とも主キーであるとすれば、SQL JOINは最初のソリューションで非常に効率的になります。

IMO 最初のソリューションは、(すなわち、その電話番号など、... WHERE LEFT(phone, 1) != '$'など、部分文字列を考慮せずに、公開されているユーザーのみを選択)あなたは効率的な方法での表示設定に基づいてSELECT Sを実行することができますので、第二に優れています。

(この利点は、しかし、あなたの場合には関連性を持たないことがあります。)


そして、この第三の可能性があった:

id | username | phone | phone_disp | email | email_disp 
------------------------------------------------------------ 
1 | foo1  | 888-888 | 0   | [email protected] | 0 
2 | foo2  | 999-999 | 0   | [email protected] | 1 
3 | foo3  | 111-111 | 1   | [email protected] | 1 

これは、データと表示設定を一緒に保持しますが。これは、JOINを必要としない点を除いて、最初の解決策と同じです。

+0

私は既存のテーブルにcolsを追加したくないのですが、それはすでに非常に大きく、それを混乱させるとアプリのどこかで不安定になる可能性があります。 – hiprakhar

+0

@hiprakharあなたが 'SELECT * FROM ...'クエリを持っていて、カラムインデックスでデータにアクセスしている(または新しいカラムの導入であいまいになる可能性のある 'JOIN'を使用している)場合は、今後の方法。 – jensgram

+0

誰が言った? 40番か80番かそれ以外の列は珍しくありません。クエリーをリファクタリングして 'SELECT *'を削除すれば、不安定さが解消されます。 – Andrew

0

列データのプレフィックスとしてではなく、表の列として表示設定を保持します。文字列のマッチングを行うことなく、クエリをより簡単に、より高速に行うことができます。データベースクエリロジックとアプリケーションロジックを分離することができます。可視性の列を同じテーブルに配置することに関するOPのコメントは、おそらく最善の方法です。

+0

@Michael前に書いたように、テーブルにはすでに40個のタイルがあり、複数のタプルがあります。同じ表に可視性の高い列を追加すると問題が追加されますか?特に私はPHPコードでselect *を使用していますか?また、データベースの正規化ではnoを指定しています。小規模でいくつかのテーブルに分散された列です。 – hiprakhar

+2

通常のクエリでは 'SELECT *'を使わないでください(あなたがすべてのフィールドを提示したサブクエリを照会するときだけ、なぜ自分自身を繰り返すのでしょうか?必要なデータを明示的に取得する習慣を身につけてください。 – Andrew

+0

@Michael @Andrew私はちょうど自分のアプリケーションコードをチェックしました。ありがたいことに、私はどこでも 'SELECT *'を使用していません。私は明示的にデータを取得するcolsを定義しています。 Phew ...(私は 'SELECT *'が悪い習慣であると知っていました。可視性の欄をデータと一緒に置くことの他の欠点は何ですか? – hiprakhar

2

多くの列を持っていると、多くの可視性フラグが発生します。元のテーブルの単一の可視性の列を、各フィールドのビットが表示される整数値で保持する方法はありますか。

define(VISIBLE_PHONE, 0x00000001); 
define(VISIBLE_EMAIL, 0x00000002); 
define(VISIBLE_DOB, 0x00000004); 

これらのビットは一緒に表示され、可視性値を作成します。

第三の選択肢についてどのように
if (row->visibility & VISIBLE_PHONE) 
{ 
    // display phone number 
} 
+0

+1バイナリフラグが不足しています。 – Andrew

+0

@ qbert220 "たくさんの列があれば、多くの可視性フラグが得られます。まさにその問題です。それで、私は各列にフラグ値の接頭辞を付けることを考えました。これにより、既存の機能を壊す可能性が最小限に抑えられます。 – hiprakhar

+1

データのセマンティクスを破ると、テーブルに列を追加するよりもはるかに大きなダメージをシステムに与えます。プレフィックスを付けないでください。別の言い方をすると、既存の機能を破壊する可能性は最小ですか?だから私は電子メールを送信しないと思います。なぜなら、文字の追加を開始すると、スクラブするためのコードを追加することなく、電子メールを送信するための既存の機能が破られるからです。 – Andrew

関連する問題