1

Facebookのように「いいね」システムを実装しなければならないWebアプリケーションを開発しています。アプリケーションには、顧客が「好き」にできる製品のいくつかのカテゴリがあります。それで私はデータベースを作り始めました、しかし私は一つの障害に固執しました。私が理解しているように、これを行うには2つの方法があります。

初め。「id、user_id、item_category、item_id」のフィールドを持つ1つのデータベーステーブルを作成します。ユーザーが「いいね」ボタンをクリックすると、さまざまなカテゴリの製品（item_category）とともにこのテーブルに情報が保存されます。

2番。アイテムの特定のカテゴリに対していくつかのテーブルを作成します。たとえば、「user_id、item_id」のフィールドを持つ「tbl_item_category_1、tbl_item_category_2、tbl_item_category_3」。

この種のデータベース構造のベストプラクティスについてより多くの洞察を得るのは素晴らしいことです。どちらが速く動作しますか？そしてより論理的/実用的ですか？いくつかのカテゴリのアイテムのみを使用します。

4

3 に答える 3

2

私はこれに似たテーブル構造を持つ最初のバージョンを使います：

User Table: PK id
id
username

Category Table: PK id
id
categoryname

Like Table: PK both user_id and catgory_id
user_id
category_id

これは、ユーザー別の「いいね」の総数とカテゴリ別の「いいね」の総数を示す2つのサンプルクエリを含むテーブル構造のデモを含むSQLフィドルです。

2つ目は、複数のテーブルを作成することはひどい考えです。50〜100のカテゴリがあり、それらのテーブルをクエリしようとすると、ひどいことになります。それは完全に手に負えなくなるでしょう。

合計いいねを取得しようとしている複数のテーブルがある場合は、次のようになります。

Select count(*)
from category_1
JOIN category_2
    ON userid = userid
join category_3
    ON userid = userid
join .....

1つのテーブルを使用してください。質問はありません。

于 2012-05-31T10:45:08.993 に答える
1

最初の方法は正しい方法です。アイテムカテゴリに対して複数のテーブルを作成しないでください。コードの保守が悪夢になり、クエリが醜くなります。

実際、一般的なルールとして、動的なもの（つまり、変更されるもの）は、静的オブジェクトのセット（テーブルなど）として保存しないでください。後で新しいタイプの「何か」を追加する可能性があると思われる場合は、 「何か」タイプのテーブルが必要です。

たとえば、ユーザーが気に入ったアイテムの数を数えようとしていると想像してみてください。最初の方法では、を実行できますがSELECT COUNT(*) FROM likes WHERE user_id = 123、2番目の方法では、JOINまたはUNIONを実行する必要があります。これは、パフォーマンスと保守性に悪影響を及ぼします。

于 2012-05-31T10:44:11.403 に答える
0

最初の方法は正しい方法です。カテゴリがいくつあるかわからず、データを取得するのが非常に難しいためです。

于 2012-05-31T10:45:23.407 に答える