如果能達到相同目的，資料越少絕對比較好，畢竟時間真的很寶貴。

如果您認同，第一個就是最適合的方式，因為解析字串不會比查詢資料庫來得久。

當然，必須要能達到相同目的才適用。

第一種寫法比較死，基本上沒彈性，可是很直覺。基本上，不想太複雜就這樣簡單做。但是，碰到數量的問題，例如：這個位置的圖要輪播，可能會有數張圖。這時候，這樣寫會很困擾，欄位得增加，數量還要先設上限。

如果要彈性的話，就要用你的第二種方法。不過，你列出來的少了一點東西：分類。因為你的產品圖不會只有一個地方有，會有列表的縮圖、內文的大圖（可能好幾張）。也許你會有行銷頁，圖檔尺寸又不同。這時候，應該再加上分類的表格。

photo_category
category_id(PK), path, width, height, quantity

photos
photo_id(PK), category_id(FK), file_name, product_id(FK)

product
product_id(PK), product_name
說明：PK=primary key, FK=foreign key

這種方式你可以把每個位置定義好，做個介面專門管理圖檔。

再延伸，如果你要把整個網站的圖都用這個表格處理的話，要怎麼做？像是：文章的圖。可以思考看看。

我是選第二種方儲存~
畢竟有些產品圖片有優先排序的觀看問題@@..

1.有時候要調整順序~方便改
2.或者該張圖片有問題~要更換
3.或者圖片授權有問題先暫時或指定會員才能看
4.或者限定期間才顯示出來