4

私は設計中のニュース システムを持っています。最初は簡単に思えましたが、計画したスキーマを進めていくうちに問題にぶつかりました... 誰でも助けることができますか？

このシステムでは、最新の 20 件のニュース記事をデータベースから取得する必要があります。このようにブログ風です。各記事には、親記事からアクセスできるサブ記事 (通常は約 3 つ) を含めることができます。サブ記事は、親記事が表示されている場合にのみ表示されます。他の場所では使用されません。

クライアントは、ニュース記事を非表示/表示できる必要がありますが (簡単)、必要に応じて順序を変更することもできます (難しい)。

最初はサブ記事を別のテーブルに保存していましたが、フィールドが本質的に同じであることに気付きました: 見出し、コピー、画像。では、それらすべてを 1 つの大きなテーブルにまとめてみませんか?

今、私は注文に関する他の問題にぶつかりました。金曜日の夜なのに頭が痛い！

誰でもアドバイスを提供できますか？

ありがとう。

更新:人々は私の「既存の」スキーマを確認するよう求めてきました:

articleID *   
headline  
copy
imageURL
visible
pageOrder

subArticleID *
articleID 
headline
copy
imageURL
visible
pageNumber
pageOrder

これは機能しますか？ユーザーが順序を変更できるようにするにはどうすればよいですか? 私にはそれを行うのは間違っているように思えたので、これを捨てました。

4

5 に答える 5

2

あなたが説明したことに基づいています。私は2つのテーブルを使用します。最初のテーブルには、すべての記事とサブ記事が含まれます。2 つ目は、記事をサブ記事に結び付けます。

最初のテーブル ( と呼びますarticles) には、次の列が含まれる場合があります。

+-----------+----------+------+----------+---------+------------+-----------+
| articleID | headline | copy | imageURL | visible | pageNumber | pageOrder |
+-----------+----------+------+----------+---------+------------+-----------+

2 番目のテーブル ( と呼びますarticleRelationships) には、次の列が含まれる場合があります。

+-----------------+----------------+
| parentArticleID | childArticleID |
+-----------------+----------------+

列でこれを既に達成しているかどうかはわかりませんpageNumberが、そうでない場合は、次のような列を追加してarticleLevel、メイン記事に 1、メイン記事のサブ記事に 2、サブ記事に 3 のようなものを追加できます。レベル 2 の記事など。このように、グラブする最新の 20 件の記事を選択するときは、テーブルから選択するだけですarticleLevel = 1。

各記事に日付/時刻を保存して、それで注文できるようにすることもおそらく役立つと思います。他の注文に関する限り、私がより多くの助けになるためには、それについてもっと明確にする必要があります.

ユーザーに表示するには、AJAX を使用します。最初に最新の 20 件のメイン記事を画面に表示し、ユーザーが特定の記事のサブ記事を表示することを選択したら、AJAX を使用してデータベースを呼び出し、次のようなクエリを実行します。

SELECT a.articleID, a.headline
FROM articles a
    INNER JOIN articleRelationships ar ON a.articleID = ar.childArticleID
WHERE ar.parentArticleID = ? /* ? is the articleID that the user clicked */
ORDER BY articleID
于 2012-05-22T12:40:13.493 に答える
2

最初はサブ記事を別のテーブルに保存していましたが、フィールドが本質的に同じであることに気付きました: 見出し、コピー、画像。では、それらすべてを 1 つの大きなテーブルにまとめてみませんか?

参照整合性は同じではないためです。

これはもちろん、ツリーを正確に 2 レベルに制限したい場合です。より一般的なデータ モデルが必要な場合は (後でアプリケーション レベルで制限することになる場合でも)、先に進んで一般的なツリーを作成します。

これはおそらく次のようになります。

ここに画像の説明を入力

PARENT_ARTICLE_ID と ORDER の両方が NULL 可能であること (つまり、ルートを表すことができる) と、両方がU1上の図の で示される UNIQUE 制約を構成すること (したがって、同じ親の下で 2 つの記事があいまいに順序付けられることはありません) に注意してください。

于 2012-05-18T20:47:05.237 に答える
1

クライアントは、ニュース記事を非表示/表示できる（簡単）だけでなく、必要に応じて順序を変更できる（難しい）必要があります。

この特定の点で、クライアント固有の順序をテーブルに格納する必要があります。これをどのように行うかは、部分的には、記事とサブ記事をどのように扱うかによって異なります。これらの線に沿った何かが記事に機能します。

client_id   article_id   article_order
-- 
1           1067         1
1           2340         2
1             87         3
...

おそらく、テーブル名と列名を調整する必要があります。

create table client_article_order (
  client_id integer not null,
  article_id integer not null,
  article_order integer not null,
  primary key (client_id, article_id),
  foreign key (client_id) references clients (client_id) on delete cascade,
  foreign key (article_id) references articles (article_id) on delete cascade
) engine = innodb;

article_orderを整数にしましたが、代わりに他のデータ型を使用するのに適したケースを作成できます。float、double、またはvarchar（n）を使用できます。再注文は面倒な場合があります。

クライアントIDが必要ない場合は、記事の順序を記事のテーブルに保存できます。

しかし、これはDrupalとWordpressが箱から出してすぐに行うようなもののように聞こえます。このホイールを再発明する説得力のある理由はありますか？

于 2012-05-22T12:17:10.703 に答える
0

SlideID は SubSlideID を「所有」しているため、2 番目のテーブルには複合主キーを使用します。

PrimaryKey: slideID, subSlideID
Other index: slideID, pageNumber, pageOrder   (Or however they get displayed)

これについて指摘したいブログ投稿の 1 つはhttp://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspxで、その理由が非常にうまく説明されています。

Auto_Increment で返信している場合、それも (MyISAM テーブルで) 処理できますが、subSlideID を auto_increment に設定することもできます。

3 番目のレベルに進む可能性が高い場合は、マージしてください。上記の Branko に従ってください。しかし、非常に複雑になり始めるので、2 層だけに分けてください。

于 2012-05-22T11:13:36.143 に答える
0

親記事のニュース ID を含むニュース (記事) テーブル「親」に新しいフィールドを作成します。この新しいフィールドは、記事とサブ記事の間の接続として使用されます。

于 2012-05-18T18:28:35.317 に答える