2011-02-27 70 views
0

我需要一些想法如何處理我正在工作的網站的數據庫結構,我一直在扼殺我的大腦一段時間,以找出最好的方式來設計表格來幫助它變得可擴展。這裏是細節。1-many-many的數據庫結構

  • 上市:一個標題文本,發佈日期和簡單的其他信息的單一職位。將與用戶表連接以獲取用戶名。

  • 標籤:每件物品可以有屬於 '類型' 示例幾個標籤:

    類型:動作,超自然喜劇

    製片人:日出,骨頭

  • 額外的字段:每個上市可以有額外的字段也舉例:

    空氣日期:2010年12月18日

    所需時N:120分鐘

標準化的方法是這樣的:

- Listing_table(LIST_ID,USER_ID,LIST_TITLE,list_content,list_date)

- Tags_table(TAG_ID,TAG_TYPE,TAG_NAME ,tag_slug)

- Tags_Listing_table(LIST_ID,TAG_ID)

- Field_table(LIST_ID,FIELD_NAME,FIELD_VALUE)

這個結構會好嗎?另外什麼是有效查詢所有這些信息的最佳方法。我認爲根本不可能在一個查詢中得到所有這些。我有什麼選擇?

而且每個上市將加載多個線程,這些線程內將有多個帖子,都在同一頁上有點像:

[單頁]

上市(標題,內容,標籤,多餘的字段)

  • 線程1
    • 張貼1
    • 後2
  • 線程2
    • 後1
    • 後2

感謝大家誰幫助,我真的很希望得到一些見解大家。如果還有什麼我可以添加來幫助你,請問。我可以轉儲我的SQL結構。

回答

2

無論你的目標的可擴展性和性能,你幾乎肯定會後悔的:

-- Field_table (list_id, field_name, field_value) 

對於一些具體原因,看SQL Antipatterns Strike Back。該結構從幻燈片16開始。還讀Bad CaRMa,這與可擴展性和性能都有關。

+0

它有什麼問題?以及如何改進?另外Wordpress使用類似的自定義字段。感謝您的輸入。 – DregondRahl 2011-02-27 18:53:00

+0

a)您不能依靠屬性名稱。一個用戶可能輸入「已創建」;其他人可能會輸入「created_on」,「date_created」,甚至「new on」。 b)熟練的數據庫管理員很難找到;這使每個臨時用戶成爲數據庫管理員。 c)數據類型和域不能幫助你。一位用戶輸入{'date_created,'2011-01-01'};另一個輸入{'date_created','昨天'}。 d)重建一行需要每個屬性一次連接。 e)每個約束必須在每個應用程序中正確執行。你幾乎沒有機會在每次應用程序中獲得正確的結果。 – 2011-02-27 20:45:20

+0

嗯,也許如果 a)如果字段名稱是預先決定的,並且在PHP本身它將會一樣。 B)耶分貝管理員都很難找到 c)中的Javascript日期系統可以被用於該所以它總是一個特定的字段或格式轉換爲時間戳 d)是這就是問題所在= [任何溶液處理它? e)真實但是處理它的替代方法是什麼? – DregondRahl 2011-02-27 22:06:16

0

這看起來像一個典型的entity-attribute-value方法。這種模式很好,特別是對於高流量的網站,但它不適合SQL。相反的:

select * from Listing_table where postdate > '2011-02-01' 

你會發現自己寫查詢:

select * 
from Listing_table lt 
where (select value from field_table ft where lt.list_id = ft.list id 
     and field_name = 'postdate') > '2011-02-01' 

而這僅僅是一個簡單的日期進行比較。這變得非常複雜。

基本上,EAV是一個折中的地方,你使用數據庫主要用於持久性存儲,少用邏輯和報告生成。

+0

列表表本身具有postdate(list_date),字段表只包含不會被搜索的值,例如TVshow的運行時間或最初開始播放的日期。這些字段不會被搜索。問題是每個列表中的字段都不相同,這就是爲什麼我將它分開的情況,否則會有NULL行。 – DregondRahl 2011-02-27 18:57:07