目前設計一個頁面會記錄是否要針對該漏洞進行開單並插入到DB TABLE如下範例。
如果需開單的話會將isEvent紀錄為y且會輸入單號；不需開單的話會將isEvent紀錄為n且不須輸入單號，但每一個站點可能的漏洞有複數個，所以可能會一次插入多個值到資料表裡。
想問的是這樣的設計是不是不太好，因為有些不會插入值，預設的話都會記錄單號，除了少數該站點再測試東西才會將isEvent紀錄為N，所以不曉得是否要正規化或是有其他的設計可以參考，資料表的後續用途主要為追蹤狀態是否處理完成
| eventNO | isEvent | hostname | pluginName | status |
|---|---|---|---|---|
| e123456 | Y | 35.201.227.252 | A漏洞 | 處理中 |
| e123456 | Y | 35.201.227.252 | B漏洞 | 處理中 |
| null | N | 35.206.194.139 | A漏洞 | 結案 |
| null | N | 35.206.194.139 | B漏洞 | 結案 |
| null | N | 35.206.194.139 | C漏洞 | 結案 |
| e222365 | Y | 35.206.194.140 | D漏洞 | 處理中 |
已邀請的邦友 {{ invite_list.length }}/5
這樣的設計是不是不太好
只要能滿足使用者的要求，就是好
如果我是使用者的話，就太不好了
建議修改如下：
1.isEvent 欄位拿掉，根本不需要(以你的設計，沒單號就是 N，有單號就是 Y)
2.加上個 EventDateTime 欄位，以記錄漏洞發生時間
3.eventNO 不要重覆(否則我講e123456時，你不知道我在講A漏洞還是講B漏洞)
1.好的，我再拿掉，看起來真的蠻多餘的
2.時間的話，我有插入createdTime/createdUser，但沒有特別列出來。
3.eventNO的話我的出發點，主要是每個hostname站點所掃出的漏洞，可能會有複數以上的漏洞，日後該站點的owner都需將漏洞修復完畢，我才設計都掛在同一個eventNo底下；
3.eventNO的話我的出發點，主要是每個hostname站點所掃出的漏洞，可能會有複數以上的漏洞
這就要看你對 eventNO 的定義是什麼了
一個eventNO是一個案件(一或多個漏洞)或是一個漏洞
以你現在的設計
當 A 漏洞status=結案，B 漏洞status=處理中 時
eventNO=e123456 的 status 會有兩種
你要顯示那一種
eventNO一律給號
如果isEvent=Y時eventNO需要連號
y=>e123456,e123457...
n=>x000001,x000002...
unique 只需要eventNO not null 即可
iThome鐵人賽
看影片追技術