これをどのように実装するかを決定しようとしています。あなたの経験が私に役立つことを願っています。
問題
ユーザーが Facebook API を使用して webapp にログインすると、一連のデータ、名前、Facebook ID (サイトでユーザーを識別するためにその番号を使用しています)、年齢、および後で保存する必要があるその他のランダム データが得られます。分析。その後、ユーザーはチケット (php スクリプトで生成された数字を含むテキスト) を要求できます。チケットが生成されると、ユーザーの Facebook ID、日付 (MM/DD/YYYY)、そしてもちろんチケットの一意の ID。同じユーザーが複数のチケットを要求できます。
解決策 1 (整理されたものですが、mysql サーバーにとってストレスが多いようです)
2 つのテーブルを作成するにはusers、Facebook ユーザー ID を含む、Facebook API から取得したすべてのユーザー個人情報を格納する場所を呼び出します。2 番目のテーブルは、チケットの作成日とそれを作成したユーザーの facebook ユーザー ID のみを格納する場所と呼ばれTickets、もちろん、このテーブルには、チケット自体を識別するための自動インクリメントの一意の ID があります。
将来的には、チケットを作成したすべてのユーザーのリストを表示し、Facebook ユーザー ID だけでなく個人情報も表示する必要がありますtickets。 facebook idusersそのユーザーの個人情報 (名前、年齢など) を取得するためにクエリを実行する必要があります。したがって、10000 人の一意のユーザーによって作成された 10000 のチケットがある場合、Mysql サーバー 10001 にクエリを実行する必要があります。1 つはチケットの配列を取得するため、10000 は各ユーザーの情報を取得するために...
解決策2（私が好きなように整理されていません）
テーブルを 2 つ持つ代わりに、チケットとユーザー データのすべてを格納するテーブルを 1 つだけ持つため、ユーザーがチケットを作成すると、チケットに関連する情報だけでなく、ユーザーの個人データも同じテーブルに格納されます。チケットを作成したユーザーのリストを表示したいのですが、単一のクエリを作成して、tickets最終的に (チケットが 10000 枚ある場合) データの大きなパックを取得し、後でそれを php を使用して解析します。このようにして、クエリは少なくなりますが、データは大きくなります。
現在、最初のソリューションの基本的な実装を実行していますが、スケーラビリティの問題について少し心配しています。
これは私のusersテーブルの一部がどのように見えるかです:
そして、これはticketsテーブルです：
したがって、ユーザーをリストするには、次のように進めます。discount_idfromticketsはチケットのタイプを表すので、タイプが必要な場合は1* チケット WHERE discount_id=1 を照会します。配列からwinner_id(チケットの作成者の Facebook ユーザー ID) を使用して取得しface_idますusers。個人情報を取得します。
私はこれを解決するための 3 番目の方法を考えていました。つまり、1 と 2 を組み合わせて、同じ 2 つのテーブルを持ち、必要な型をクエリした直後に、すべての配列を要求するtickets(1 つだけの) テーブルをクエリします。usersユーザーIDticketsが私にくれましたが、これを行う方法と、それが価値があるかどうかはわかりません。
どちらのソリューションが優れていますか? スマートに進める方法はありますか？ありがとう！