web开发之附件数据库设计

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的记录。