數據庫表，可以說漢堡，包含一個字段，存儲位爲整數值，所以它的值爲1,2,4,8,16 .. 。多對多的關係，比較明智的比較與鏈接器表
一種二次表包含值 1 =奶酪，2 =番茄，4 =蛋，8 =萵苣，16 =蛋黃醬
逐位比較然後使任何漢堡具有餡料的任何組合（對於一位24歲的初生漢堡會有mayo和生菜（16 + 8），而val 5的漢堡會有奶酪和雞蛋等）。
據我所知，這不是一個特別好的主意，你只限於相對較小範圍的不同漢堡餡（64？）。唯一的好處是它可以節省數據庫空間，因爲不需要鏈接器表。
但是，我接手的是一個技術上非常好的人，那麼我是否還有其他好處？在我看來，有兩個負面因素：它限制了不同餡料的數量，以及它的奇怪/不尋常（從記憶成爲主要考慮的時候掛斷了）。
我看到的唯一好處是，它可以使返回包含所有漢堡配料和其他數據的逗號分隔字段在一行中的相對容易。不速之客，我不知道如何做到這一點。如果是這種情況，我會很樂意看到那個SQL。
如果前端程序從輔助表中緩存數據並在返回後分析按位字段，它也會消除對數據庫的調用。
但是，我沒有看到任何其他好處。我只是使用一個鏈接器表並完成它，因爲我認爲，比特封裝使數據庫設計複雜化。
以這種方式使用位掩碼，您將無法利用SQL參照完整性檢查的強大功能。如果以某種方式輸入值128，會發生什麼？查找表中沒有這樣的條目。如果我試圖加載一個查找表中不存在的值，我會得到一個錯誤，並且該值將（正確）不會被加載到數據庫中。
它可能會更快，更容易（和更有趣的），以實施位運算符，但適當的標準化數據庫可以更容易支持了很多，並保持一段時間。
你可以通過添加表，將 看起來像繞開這個問題的解決方案：
Table: Fillings
Id Cheese Tomato Egg Lettuce Mayo
0 N N N N N
1 Y N N N N
2 N Y N N N
3 Y Y N N N
...
31 Y Y Y Y Y
那麼你可以說：
select
count(1) as WithCheeseButNoTomato
from Burger as b
join Fillings as f on f.Id = b.FillingId
where Cheese = 'Y'
and Tomato = 'N' ;
任何假定的好處是在前端填充選區或在應用程序層。