若使用關聯式資料庫
我的設計邏輯為
表 category
-id
-name
表 product
-id
-category_id
-name
表 image
-id
-product_id
-file
想請教一下 若使用MongoDB設計
把所有資料儲存在同一個collection是合理的嗎?
類似的儲存資料格式為
{
"_id": 1,
"name": "戒子",
"products": [
{
"_id": 1001,
"name": "豬鼻戒子",
"images": [
{
"_id": "image1",
"file": binary
},
{
"_id": "image2",
"file": binary
}
]
},
{
"_id": 1002,
"name": "狗鼻戒子",
"images": [
{
"_id": "image3",
"file": binary
}
]
}
]
}
因為平常都是使用關聯式資料庫 想請問這樣設計是合理的嗎? 目前想到的問題是每次讀取資料會因為有包含binary檔案導致讀取速度偏慢?
還有就是想請教 在儲存檔案時,轉成binary儲存至資料庫,與實際儲存實體檔案在伺服器的差異性是?該如何選擇要存binary還是存實體檔案呢?
MongoDB 設計上不是不能有關聯,只是結構上不幫你確保關聯性
在 RDBMS 上有 FK (Foreign Key) 確保關聯,但 MongoDB 不存在
你依然可以使用你原先設計的資料結構設計三個 Collection,由 AP 端去查詢關聯性的資料。
這裡需要釐清一下:
Collection 對應到的是 RDBMS 的 Table
Document 對應到的是 Raw
所以應該是將資料存入單一 Document 才對。
MongoDB 文件-大小上限
單一 Document 最大上限是 16MB,所以不應該將 binary 直接存在 BSON,你需要另外啟用 MongoDB 文件-GridFS
能看得出來主要的設計是由 category 為主要並且將相關的 product 放入,比較需要擔心的就是這樣的設計會有機會將所有商品集中於單一 category 的 Document 導致 16MB 超過,我會設計成以下,並且將 file 放置於 AWS S3 之類的檔案儲存,避免資料庫效能受到影響。
{
"_id": 1,
"name": "豬鼻戒子",
"category":"戒子",
"images": [
{
"name": "image1",
"file": "url"
},
{
"name": "image2",
"file": "url"
}
]
}
所以我會另外設計一個 category 的 Collection
{
"_id": 1,
"name": "戒子"
}
需不需要將 category 與 product 建立關聯就是看個人設計,你也可以將 category 的文字直接存於 product 而當寫入後 category 與 product 就再無關聯性。