web開發中，經常會遇到附件的上傳功能，這裡針對web應用的附件的資料庫設計發表自己的看法。

假設開發一個類似於新浪微博一樣的社交網路，其中的模組分為微博模組，活動模組，部落格模組；

微博模組裡面，使用者發表微博時，可以上傳圖片，而且可以上傳多張圖片；

活動模組裡面，使用者釋出活動時，可以上傳活動圖片，而且可以上傳多張圖片；

部落格模組，使用者發表部落格的時候，可以上傳圖片，而且可以上傳多張圖片；

資料庫設計（方案一）：

微博表：pre_feed

feed_id,feed_content,feed_user,feed_addtime,feed_image_1,feed_image_2,feed_image_3

活動表：pre_event

event_id,event_title,event_content,event_addtime,event_image_1,event_image_2,event_image_3

部落格表：pre_blog

blog_id,blog_title,blog_content,blog_user,blog_addtime,blog_image_1,blog_image_2,blog_image_3

方案一缺陷：

每個模組的附件數量不夠靈活，假設系統要改成上傳5張圖片的情況下，需要修改資料庫的結構。

資料庫設計（方案二）：

微博表：pre_feed

feed_id,feed_content,feed_user,feed_addtime,feed_image

活動表：pre_event

event_id,event_title,event_content,event_addtime,event_image

部落格表：pre_blog

blog_id,blog_title,blog_content,blog_user,blog_addtime,blog_image

然後設計一張附件表專門用來存放整個系統的附件資訊，不僅僅限於圖片格式的附件，附件表包含了該附件是存放於哪臺伺服器，屬於系統的哪一個個模組，哪一張表，哪一條記錄等詳細資訊。

附件表：pre_attach

attach_id,attach_domain,attach_module,attach_table,attach_row,attach_type,attach_save_name,attach_save_path,attach_size,attach_width,attach_height,attach_extension

而表pre_feed的feed_image，pre_event的event_image，pre_blog的blog_image，設計成字串的資料型別，對應附件的表的主鍵attach_id所組成的字串，所以，有多個附件的情況下，直接存入的類似於1,2,3,4的資料，表示該記錄有4個附件，對應附件表裡面attach_id=1,2,3,4的記錄。