新聞系統的數據庫模式

Question

我有一個我正在設計的新聞系統，起初看起來很簡單，但是當我推進我計划好的架構時，我遇到了問題......顯然我沒有想到它。 有人可以幫忙嗎？

系統要求從數據庫中獲取最新的20篇新聞文章。 這樣就像博客一樣。 每篇文章都可以包含可以從父文章訪問的子文章（通常大約3個）。 只有在父文章可見時才能看到子文章 - 它們不會在其他地方使用。

客戶需要能夠隱藏/顯示新聞文章（簡單），但如果他們願意（更難），也需要改變他們的訂單。

我最初將子文章存儲在一個單獨的表中，但后來我意識到這些字段基本相同：標題，復制，圖像。 那么為什么不把它們全部放在一張大桌子上呢？

現在我在訂購時遇到了其他問題。 這是星期五晚上，我的頭疼！

有人可以提供建議嗎？

謝謝。

---

更新：人們要求查看我的“現有”架構：

articleID *   
headline  
copy
imageURL
visible
pageOrder

subArticleID *
articleID 
headline
copy
imageURL
visible
pageNumber
pageOrder

這會有用嗎？ 我如何讓用戶更改訂單？ 這對我來說似乎是錯誤的方式，所以我把它扔掉了。

Answer 1

我最初將子文章存儲在一個單獨的表中，但后來我意識到這些字段基本相同：標題，復制，圖像。 那么為什么不把它們全部放在一張大桌子上呢？

因為參照完整性不一樣。

當然，如果你想將樹限制在2個級別。 如果您想要更通用的數據模型（即使這意味着稍后在應用程序級別限制它），那么繼續創建一般樹。

這可能看起來像這樣：

請注意PARENT_ARTICLE_ID和ORDER都是NULL（因此您可以表示根）以及兩者如何構成上圖中由U1表示的UNIQUE約束（因此在同一父項下不能模糊地排序兩篇文章）。

Answer 2

根據你所描述的內容。 我會用兩張桌子。 第一個表格將包含所有文章和子文章。 第二個將文章與他們的子文章聯系起來。

第一個表（稱為articles ）可能包含以下列：

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

第二個表（稱之為articleRelationships ）可能包含以下列：

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

不確定你是否已經使用pageNumber列實現了這一點，但如果沒有，你可以為articleLevel添加一個列，並為主要文章提供類似於1的內容，為主要文章的子文章提供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

Answer 3

客戶需要能夠隱藏/顯示新聞文章（簡單），但如果他們願意（更難），也需要改變他們的訂單。

在這一點上，您需要在表中存儲特定於客戶端的排序。 具體如何做到這一點將部分取決於您如何選擇處理文章和子文章。 沿着這些方向的東西將適用於文章。

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開箱即用的東西。 是否有令人信服的理由重新發明這個輪子？

Answer 4

在新聞（文章）表“parent”中創建一個新字段，其中包含父文章的新聞ID。 此新字段將用作文章和子文章之間的連接。

Answer 5

由於SlideID“擁有”SubSlideID，我會為第二個表使用復合主鍵。

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

我更喜歡指出的一篇博文是http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx，因為它解釋了為什么非常好。

如果您正在回復Auto_Increment，也可以處理（使用MyISAM表），您仍然可以將subSlideID設置為auto_increment。

如果您可能會進入第三級然后合並 - 請按照上面的Branko進行操作。 但它確實開始變得非常復雜，因此僅保持2層分開。