推 d1288999: 以前用過下面那種，當時也是覺得比較有彈性，後來還是 04/13 00:47
→ d1288999: 改回 column ，用 row 的方式要查一些屬性或 join 都很 04/13 00:47
→ d1288999: 麻煩 04/13 00:47
→ JYHuang: 不過這一個table規劃是純粹存放參數用，不會與其它table 04/13 23:45
→ JYHuang: 做到關聯。這一點覺得還比較沒差 04/13 23:45
簡單說就是系統許多使用者，每個使用者都會有不同的參數。
還在開發階段時會新增參數和調整參數的形態。
目前用的方法是一個使用者一個row
欄位架構大概如下
ID , Protocal , Port , Server
1 , http , 80 , url.com
2 , ftp , 21 , url1.jp
有在考慮改成這樣的架構，開發上會比較有彈性
ID , Key , Val
1 , Protocal , http
1 , Port , 80
1 , Server , url.com
架構的標準放在另一個表，用JOIN的方式以另一個表做預設值。
用 INSERT .. ON DUPLICATE KEY UPDATE 來做新增或更新 key/val 的判斷
不知道這樣放參數在使用者一多時會不會比較佔空間
另外和前者的存放上有何種優劣呢？
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 60.249.195.11
※ 文章網址: https://www.ptt.cc/bbs/Database/M.1491803741.A.6D3.html