2

私はまだPHPに慣れていないので、どちらの方法が良いのか、誰かがより良い方法を提案できるのではないかと考えていました。

私には一連のユーザーがいて、投稿とのすべてのインタラクションを追跡する必要があります。ユーザーがボタンをタップすると、投稿がリストに追加され、もう一度タップすると投稿が削除されるため、次のようにするとよいでしょう。

各ユーザー（おそらく数千人）のテーブルにpostIDのJSON配列の列を格納します。

-また-

保存（postIDとuserIDの組み合わせ）（おそらく数百万）ごとに個別のテーブルを用意し、userIDが一致するすべての結果を返しますか？

この質問の目的のために、2つのテーブルがあります。テーブルAはユーザーであり、テーブルBは投稿です。ユーザーの保存済み投稿をすべて保存するにはどうすればよいですか？

編集：申し訳ありませんが、投稿には複数のユーザーインタラクションがあり、ユーザーには複数の投稿インタラクションがあります（多対多の関係）。それはボブの答えに影響を与えると思います。

4

3 に答える 3

2

この質問の目的のために、2つのテーブルがあります。テーブルAはユーザーであり、テーブルBは投稿です。ユーザーの保存済み投稿をすべて保存するにはどうすればよいですか？

各ユーザーが何らかの一意のID（主キー）を持っている場合は、ユーザーの一意のIDを参照するフィールドを各投稿に追加します。

mysql> describe users;
+----------+------------------+------+-----+---------+----------------+
| Field    | Type             | Null | Key | Default | Extra          |
+----------+------------------+------+-----+---------+----------------+
| id       | int(11) unsigned | NO   | PRI | NULL    | auto_increment |
| email    | varchar(200)     | YES  |     | NULL    |                |
| username | varchar(20)      | YES  |     | NULL    |                |
+----------+------------------+------+-----+---------+----------------+

mysql> describe posts;
+---------+------------------+------+-----+---------+----------------+
| Field   | Type             | Null | Key | Default | Extra          |
+---------+------------------+------+-----+---------+----------------+
| id      | int(11) unsigned | NO   | PRI | NULL    | auto_increment |
| user    | int(11) unsigned | NO   |     | NULL    |                |
| text    | text             | YES  |     | NULL    |                |
+---------+------------------+------+-----+---------+----------------+

次に、ユーザーの投稿を取得するには、たとえば次のようにします。

SELECT text
 FROM posts
 WHERE user=5;

または、特定の組織からすべての投稿を取得するには：

SELECT posts.text,users.username
 FROM posts,users
 WHERE post.user=users.id
   AND users.email LIKE '%@example.com';
于 2012-06-06T21:29:20.030 に答える
2

これは興味深い質問です！

解決策は、実際に予想されるユースケースによって異なります。各ユーザーがタグ付けした投稿のリストを持っていて、それが必要なすべての情報である場合、これらをユーザーのテーブル（または、nosqlバックエンドを使用している場合はblob）のフィールドとしてリストすると便利です-これがあなたのユースケースであるなら、実行可能なオプションです！）。リストはどちらの方法でも同じサイズになるため、送信時間への影響はありませんが、このソリューションでは、1つのテーブルのみを使用し、dbsが最適化してこの情報を近づけるため、ルックアップ時間を節約できます。

一方、特定の投稿にタグを付けたすべてのユーザーについてクエリを実行できるようにする必要がある場合は、オプション2の方がはるかに優れています。前者の方法では、すべてのユーザーにクエリを実行し、各ユーザーに投稿があるかどうかを確認する必要があります。このオプションでは、すべての関係を見つけてそこから作業する必要があります。おそらく、userテーブル、postテーブル、およびuser_post最初の2つのテーブルへの外部キーを持つテーブルがあります。これを行う方法は他にもありますが、複数のリストを維持し、毎回クロスチェックする必要があります。これは、コストのかかる一連の操作であり、エラーが発生しやすくなります。

dbはこの種のクイック読み取り用に最適化する必要があるため、後者のオプションは「数百万」の接続を詰まらせるべきではないことに注意してください。（プロのヒント：適切な列にインデックスを付けてください！）ただし、データマッサージには注意してください。不要なforループが1つあると、パフォーマンスが低下します。

于 2012-06-06T21:19:45.970 に答える
0

すべての投稿ステータスデータとなる3番目のテーブルを保持することは理にかなっていると思います。

たとえば、ユーザーインターフェースに1ページあたり50件の投稿が表示されている場合、UIは一度に50件の投稿を追跡するだけで済みます。それらはすべてデータベース内で一意のIDを持っているので、問題にはならないはずです。

于 2012-06-06T20:41:37.120 に答える