其實我用的方式也是 slime 用的方式

最單純的對應法。
效能方面也不太需要擔心。索引下好就行了

後期擴展也比較好。

我以前都把重心放在【儲存空間大小】、【電腦效能】上，
後來發現，空間越來越便宜，電腦越來越快，
我現在都把重心放在【程式最好寫】上頭啦。

雖然，0.01秒和0.02秒，表面上效能差了一倍，
但，對於使用者的感受來說，是一樣的。

你的DB怎麼設計是來自於需求是什麼 以及擴展性是什麼 以及 之後可能會有什麼變更
你所提供的命題其實是很難回答的
因為 你只說出了你的想法 以及前輩教你的做法
而 之後你會如何存取這個DB 這個欄位 要做什麼操作
你多常會需要寫一次這些欄位 才是考量的要點

對於效能的部分 在幾千 幾萬筆資料來說 現在的硬體跑起來不會差到很多
但是到 幾十萬 幾百萬 甚至上千萬筆的時候 就會變得很明顯
甚至於...卡死

用一攔一欄的 true/false 值來存 或者用 {"A":1,"B":0,"C":1,...} 來存
各有各的優點，當然也有其缺點
所以你問 這樣比較好 還是那樣比較好 其實是不太容易有答案的

以上淺見

"而且並不會運用這些值來搜尋" <== 這是個很奇怪的狀況
基本上,寫到資料庫的 data 都有可能用任何查詢條件來查詢(單一水果統計依月份,去年同比,....同類水果統計,...累計...)

若以查詢的角度而言 :
1.方法一 : 單一欄位儲存多資料 => 查詢 banana 時 , fruit 欄位內的字串都要額外拆解運算 ,當資料大時,時間都耗在拆解字串(甚至串聯到其他 table 做其他運算..更耗時) ,可運作但是很可能會 Timeout ,無資料回傳
2.方法二 : 資料的儲存僅限於 "apple,banana,grape,strawberry,orange"這幾個欄位,若有新增
fruit 是 Cherry 時 , 不只要新增欄位還要改 code ; 若水果本身又要分類去統計 ,....那...如何做 ?

建議作法 :
A.資料歸資料:基本上要符合正規化
B.報表歸報表:符合正規化的 table 基本上都有方法行轉列,或是列轉行
table 應該會類似 :

fruit   Employee    Qty
apple       Alex      1
banana      Alex      1
grape       Alex      0