query_stringについて - PHPプロ！Q&A掲示板
キーワード / PHP
例えば紹介者Aが
http://hogehoge.com?frend=1234を紹介者Bに渡したとしたら、紹介者Bが会員になるかを
query_stringで判断すると思うのですが、登録したかどうかの判断っていうのは登録フォームのsubmitを押したという値で判断すればいいわけですよね？
あと紹介者Bが者紹介者Aの判断っていうのは、DBに予め、frendの１２３４っていう列を作成しておくのでしょうか？
取得はわかるのですが、紹介者Aだという判断をどうやっていいかわからず質問しました。
ちょっとややこしい質問ですいません。
この質問への意見の募集は締め切られ、ポイントは既に配分されました。
意見を投稿することはできますが、ポイントを受け取ることはできません。
ツリー一覧
A03magicflute2紹介者Aさんが、Bさんの他に、複数紹介した場合を考慮
A03-1-1magicflute2その流れは理解しました。
> frendという列を作っ
A03-1-1-1-1MOREBEER今はユーザー管理テーブルの話ですね
ポイントの付
A03-1-1-1-1-1shimix>AからBに紹介する際に先にAのほうのテーブル（friendA03-1-1-1-1-1-1MOREBEERなるほど
shimixさん！本当にありがとうございましたA03-1-1-1-1-1-1-1shimix本当に理解出来ていれば、こういう質問はあり得ない気A03-1-1-1-1-1-1-1-1MOREBEER＞紹介者IDは「AさんのユーザID」ですよ？Aさんを登録A03-1-1-1-1-1-1-1-1-1shimixここまで「AさんのユーザID」と書いて話を進めているA03-1-1-1-1-1-1-1-1-1-1MOREBEERそうですね。
shimixさん、初歩的なところなどご丁寧A03-1-1-1-2magicflute2『誰に紹介された』というより、『誰を紹介した』といA03-1-1-1-2-1shimix＃雑感モードです（汗
そうですね。おそらくポイン回答一覧
A01
answererslyman [7月5日 06:59]
1)お友達に紹介するページを作る（メールフォーム or テキストコピー）
メールフォームなら本文に、テキストコピーなら画面に
http://hogehoge.com?friend=1234
を表示しお友達になんらかの手段（メール、口頭等）で教えてもらう導線を作る
2)上記URLにクリックすると、登録画面がでる。
ここでほしい情報があればフォームで取得。
上記friendパラメータはhiddenでフォーム内に記述
3)DBにBユーザー情報を登録するときに友達関係テーブルにデータを登録
たとえばこのようなテーブル
CREATE TABLE friend_relations{
my_id varchar(4),
friend_id varchar(4)
}
Bユーザーの新規登録で生成されたIDが5678であった場合
insert into friend_relations(my_id,friend_id) values ('1234','5678');
insert into friend_relations(my_id,friend_id) values ('5678','1234');
誰からの紹介で入ったか明確に分かりたい場合は別途テーブルを作成
たとえばこのようなテーブル
CREATE TABLE child_parent_relations{
child_id varchar(4),
parent_id varchar(4)
}
insert into friend_relations(child_id,parent_id) values ('5678','1234');
とでもやればいいと思います。
PHPの質問というよりはフローチャートとかERの質問だとはおもいますが。
A02
answerershimix [7月5日 10:32]
＃正直、何がわからないのかちょっと読み取れません。
で、とりあえず個別に「？」と思った部分を（汗
>登録したかどうかの判断っていうのは登録フォームのsubmitを押したという値で判断すればいいわけですよね？
登録フォームからsubmitされてデータベースに登録する時点で「紹介者」も一緒に登録します。「submitを押した」のでなければ、そもそも新規登録しないわけで・・。
>あと紹介者Bが者紹介者Aの判断っていうのは、DBに予め、frendの１２３４っていう列を作成しておくのでしょうか？
テーブルに紹介者IDの列を作っておけばいいと思います（列名が「friend」がわかりやすければそれでいいです）。
A02-2
replyerMOREBEER [7月5日 16:46]
frendという列を作ったとして、デフォルト値はIDを生成すればいいのでしょうか？
初歩的な質問ですみません。
A03
answerermagicflute2 [7月5日 18:44]
そうであるなら、既に回答がある様に、
『登録ユーザを管理するテーブル』の他に、
ユーザ同士の『つながりを管理するテーブル』が必要なのだと思いますが、
そうされていますか？
BさんのIDを、どのタイミングで、どうやって発行するのですか？
Bさんが、新規でユーザ登録する際、どの様なフローになりますか？
Bさんが、既にユーザ登録されていたら、どの様なフローになりますか？
重複した、紹介およびユーザ登録は、許可するのですか？
つながり管理テーブルで、紹介された人のIDは、一意ですか？
--
初めの段階で設計をミスると、変更が大変なので、
紙に図を描いて、この辺を明確にした方がいいと思います。
A03-1
replyerMOREBEER [7月5日 19:04]
ちょっと自分の質問の説明不足だったのですが、簡単にいえば、紹介Aが紹介Bに紹介する際に
紹介専用ページを設けて、そこに友達へ紹介するメールリンクを作成し、本文に紹介A専用のURLをクリックさせるようにします。
それから、紹介Bが新規登録した際に紹介Aに音楽ダウンロードできる、ポイントを付与したいのです。
１ｐｔで１ダウンロードみたいな。
そこで紹介Bが紹介Aの紹介で登録したと明確に判断し、紹介Aにポイントを付与する。
流れとしてはこんな感じです。
UPDATE文とSELECT文でやるとは思いますが。。。
frendという列を作ってデフォルト値に各ユーザー達の専用の値をいれてあげないと判断はできませんよね？
A03-1-1
replyermagicflute2 [7月5日 19:29]
> frendという列を作って
このカラムを何のテーブルに作ったのかを知りたいのです。
もし、ユーザ情報管理用のテーブルに、frendという列を１個追加したのであれば、
Bさんの後に、Cさんを紹介した場合、
frendカラムはもう埋まってるんじゃないですか？
なので、
> 紹介Bが新規登録した際に紹介Aに音楽ダウンロードできる、ポイントを付与したいのです
Aさんは、Bさんを紹介した分の、1pt以上受け取る事ができないと思うのですが。
つまり、
・つながりを管理するテーブルが必要では？
・紹介数は、1ユーザにつき一人なのですか？
という事です。
A03-1-1-1
replyershimix [7月5日 22:14]
私が思いついていたのは
http://example.com/?friend=（AさんのID）
でアクセスされて、Bさんを新規登録したときに、Bさんの紹介者（親）として列「friend」にAさんのIDを登録しておけばいいのでは？ということでした。そうしておけば列「friend」で並べれば、Aさんの紹介で登録されたBさん、Cさんを取得するのは簡単にできると思います（同時にBさんから紹介されたDさん、Eさん、Fさんも取得出来ますよね）。
＃列「friend」がNULLだったら「紹介者なし」での新規登録という扱いで（Aさんもそうですね）。
で、Aさんにポイントを付与するタイミングが、Bさん（あるいはCさん）の登録と同時でよければ（即時付与であれば）、Bさんを登録する時点でAさんのポイントを+1でupdateすればいいと思います。
＃付与するタイミングはけっこういろいろ考えられますので、即時付与でない場合は紹介者IDと
＃ともに（紹介者への）ポイント付与済みフラグを持っていた方が確実かもしれません。
もちろん、Aさんのポイント履歴用にBさん紹介、Cさん紹介、ダウンロードで消費・・といった明細テーブルを持っていてもいいとは思いますが、今はユーザー管理テーブルの話ですよね？
A03-1-1-1-1
replyerMOREBEER [7月6日 00:47]
ポイントの付与はわかるのですが、問題はIDなんです・・・
AからBに紹介する際に先にAのほうのテーブル（friend）列に前もってIDを生成してないと認証できませんよね？
事前に列のIDがあれば、Aからの紹介者BでもCでも認識できるわけですよね？
A03-1-1-1-1-1
replyershimix [7月6日 08:20]
>認証できませんよね？
ここでいう認証とは何を指しているのでしょう。基本的に（ポイントの加算は別にして）紹介・被紹介に関してAさんのレコードの触る必要はありません。
BさんがアクセスしたURLのQueryStringでAさん（既存ユーザ）のIDは引き渡されているのですから、Bさんの新規登録をする時点では「紹介者はAさん」という情報は保持出来ています。それを列friendに「紹介者ID」として（Bさんのレコードに）入れておけばいいです。Bさんが「Aさんに紹介されたユーザ」というのはこれでわかります。
逆に「Aさんが紹介したユーザ」は、列friend（紹介者ID）がAさんのIDになっているレコードを引っ張り出せば（当然複数件の可能性もあります）取得できます。せっかくのデータベースですから、そういう使い方をしないともったいないです。
A03-1-1-1-1-1-1
replyerMOREBEER [7月6日 12:41] (最終編集：7月6日 13:44)
shimixさん！本当にありがとうございました！理解できました！！！！！
＃紹介者IDってuniqidで作成するべきなのでしょうか？
知識不足ですみません。
追記
＞BさんがアクセスしたURLのQueryStringでAさん（既存ユーザ）のIDは引き渡されているのですから
この既存ユーザのIDというのは事前にIDをDBに登録する必要はありますよね？
ポイント付与する際にSELECT文で検索かけないと付与できないですよね。
＃既存IDはセッションで渡す必要がありますよね？
そこからSELECTでセッションの中にある例えばアドレス等を検索かければいい
という事ですかね？
A03-1-1-1-1-1-1-1
replyershimix [7月6日 13:43] (最終編集：7月6日 13:46)
>＃紹介者IDってuniqidで作成するべきなのでしょうか？
>知識不足ですみません。
紹介者IDは「AさんのユーザID」ですよ？Aさんを登録するときにどうやって登録しているんでしょう。BさんやCさんのIDはどうやって作成するつもりだったのでしょう？紹介云々以前の問題ですけど・・
>追記
>＞BさんがアクセスしたURLのQueryStringでAさん（既存ユーザ）のIDは引き渡されているのですから
>
>この既存ユーザのIDというのは事前にIDをDBに登録する必要はありますよね？
>
>ポイント付与する際にSELECT文で検索かけないと付与できないですよね。
事前に登録って・・。Aさんは既存ユーザですよね？登録済みでないユーザIDが紹介用URLに付加されることはあり得ませんよね。登録する必要云々の前に、登録されていないIDが紹介用URLに付加されることが起こってはいけませんよ。
アクセスしてきたときに（QueryStringから）IDで検索して存在しなかったら、そもそも「不正なURL（URLの一部が欠損している）」と判断すべきでしょうね。コピペしたときやメール本文の折り返しで最後の数桁が落ちるなんてことはあり得ますから。チェックするとすればこのタイミングで行うべきですし、このタイミングで行っていればじゅうぶんです（これ以降チェックしなくていいです）。基本的にポイント加算のときは（Aさんのレコードに対して）Update文だけでいいです。
A03-1-1-1-1-1-1-1-1
replyerMOREBEER [7月6日 14:21] (最終編集：7月6日 14:28)
登録するときは名前や性別、メールアドレス、個体識別番号とINT型のIDなどですが、このIDになるのですか？
ちなみにマイページは普通にセッションIDで名前などを受け渡しして表示してるだけです。
A03-1-1-1-1-1-1-1-1-1
replyershimix [7月6日 14:31]
>登録するときは名前や性別、メールアドレス、個体識別番号とINT型のIDなどですが、
>このIDになるのですか？
主キーはどれですか。IDじゃないんですか（普通はそうだろうと推測しますけど）。
というか、最初の質問の「1234」って何だったのかな・・。「?friend=1234」を渡して「Aさん」が特定できないといけないんだから「1234」はAさんを一意に識別できるIDでないとマズイでしょ。で、メールアドレスや個体識別番号を外に出すわけにはいかないだろうからシステム上で付与した「ID」を使うのが妥当じゃないですかね。
A03-1-1-1-1-1-1-1-1-1-1
replyerMOREBEER [7月6日 14:37]
shimixさん、初歩的なところなどご丁寧に回答してくださってありがとうございました。
A03-1-1-1-2
replyermagicflute2 [7月6日 01:02]
考えておりました。
また、
> 友達紹介システム
とあったので、提示された情報から、想定される機能を先読みして、
それなりの規模に膨らむだろうとも考えておりました。
そして、後から、紹介者情報、ポイント情報を分離させるのは
大変だろうと、あの回答となった次第です。
必要な機能が、最小限で実装できる方が良いでしょうし、
質問主は、それ程の規模は求めていないと、解釈しました。
ご指摘有難う御座います、また横槍失礼致しました。
A03-1-1-1-2-1
replyershimix [7月6日 08:38]
そうですね。おそらくポイントを即時付与しないとかの条件などがあると、多少面倒です＞ポイント加算システム。
アプローチとしては「Aさんのポイント履歴」をメインに考えて、ポイント付与・消費の履歴テーブル（紹介して登録したユーザのIDやダウンロードした曲の情報を含める）を作成して、紹介・被紹介もそちらから取得するという手法も考えられます。Aさんの個人ページで履歴参照を可能にする必要があれば（私なら）こちらを採用しますね。
個人的にはあちこちのテーブルや列を更新するのは整合が崩れたらどうするかとか考えないといけないので、なるべく少ないテーブル・列で済ませたいところです。極端な話「Aさんの現在のポイント」もAさんの管理テーブルに持たずに履歴テーブルから加減算してもいいんじゃないかと（このあたりはデータ量なども勘案しないといけませんけどね）。
ページのトップへ
GETのままでは検索エンジンのロボットが拾ってくれなかったためにSEO対策として有効だと言われていますね。