2010-12-02 9 views
0

私は最近この問題を解決しようとしていましたが、実際にはわかりません。 私は、ユーザーがプロファイルを登録したり作成したりできるようにするアプリケーションを持っています。 プロファイルごとに、1つのプロファイルで必要なだけ多くのキャンペーンを作成することができ、キャンペーンごとにリンクを追加することができます(リンク数は限られていますが、とにかく大きいです)。各リンクは、それ自身のキーワード(1つ以上のキーワード)を持つことができます。大きなデータベースのスキーマ

明らかに私の頭に浮かんだのは、ユーザー用のテーブル、プロファイル用のテーブル、キャンペーン用のテーブル、リンク用のテーブル、キーワード用のテーブルを持つことでした。しかし、これを考えて、いくつかのユーザーが同じキーワードを使用する可能性があり、私はデータベース上でその情報をn回繰り返したくない。私はこれがmysqlで可能かどうかわからないが、キーワードテーブルのキーワードのIDを参照するリンクテーブルのフィールドを持っていると思います。 idsの配列のようなものです。私はこの実装を柔軟にして、簡単にキーワードを取得し、「キーワードの配列」を更新し、特定の計算を実行できるようにしたいと考えています(たとえば、キーワードの数を数えます)。これを実装する方法について、可能な解決策をお勧めしますか?

私はmySQLとPHPを使用しています。 ありがとうございます。

答えて

1

あなたは、キーワードを格納するテーブルを作成する必要があります

id (int) keyword (varchar)

をIEとのリンクのためのアソシエーションテーブルを保存する - >キーワードはこのことができます

link_id (int) keyword_id (int)

希望、すなわち!あなたは(私はすべてのリンクは、キーワードを持っていると仮定しているユーザーとキーワードのIDのID、リンクのIDを格納する多くのテーブルに多くを持っている必要があり

  • クリスチャン
0

次に、通常のデータベース操作だけで話すことができます。

+0

このように、すべてのエンティティは分離されており、外部キーは指定されておらず、それらのすべてを接続する関連テーブルも存在します。それは正しいのですか? – user253530

2

私はこれらのテーブルを考え、その説明から:

user (id, ...) 
campaigns (id, user_id, ...) 
links (id, campaign_id, link) 
keywords (link_id, keyword) 
+0

'profiles(id、user_id、...)'が不足しています(つまり、 'campaign(id、profile_id ...)')。実際には実用的なスキーマ – tobyodavies

1

私はエンティティのそれぞれのテーブルのあなたの最初の実装が正しいことを主張しています。別のテーブルにキーワードを格納してlink_idなどと関連付けると、各リンクのすべてのキーワードを含む配列よりもはるかに一般的なキーワードでリンクを検索することができます。

+0

を与えるのに+1が使われます。異なるユーザーは、異なるリンクに対して同じキーワードを有する可能性がある。私はどのキーワードがより頻繁に使用されるかを見たいと思います。 – user253530

+0

次に、sqlを使用して、各キーワードの数を数えます。 keyword_tblからcount(キーワード)を選択します。またはそのようなもの –

0

2つのアイデアがあります。 1)各ユーザーに独自のキーワードセットがあります。 ユーザーテーブルがあり、userIDがFKの別のテーブルにキーワードがあります。

リンクを追加する必要のあるプロファイル/キャンペーンに関係なく、ユーザーはそのユーザーのキーワードを表示します。

リンクはまだkeywordIDとLINKID

2を開催する結合テーブルを経由してkeywordIDへリンクします)キーワードを持つ グローバルキーワードはちょうどkeywordIDとキーワード を持っkeywordIDとLINKIDを保持するために結合テーブルが存在することになりますリンクに複数のキーワードを含めることができます。

ユーザーが新しいキーワードを追加する前に既存のキーワードを検索するようにフロントエンドを作成する必要があります。これは、ダブルアップを防ぐのに役立ちます。キーワードを追加するプロセスでは、追加する前に既存の値もチェックする必要があります。

1

ユーザーが異なるリンクに対して同じキーワードを選択する可能性があると私は主張します。これは意味的に同じではありません。

driftwoodとflotsom用のキャンペーンがあり、リンク上のキーワードとして「シェル」を使用する場合、これはunixユーティリティーキャンペーンでキーワードとして使用するのと同じ "シェル"ではありません。

オリジナルのクリーンで論理的なスキーマに固執し、想像上の問題を解決して複雑にしないでください。

+0

+1私はJamesAndersonに同意します。 「キーワード」の道を始めると「キーワードルーツ」と「キーワード修飾語」を保存するように誘惑され、「シェル」はルートで修飾子は「s」、「ing」、「shock」、「shocked」、 –

関連する問題