布爾型與更具體的變量

爲了創造更好，更一致的約定，我想獲得關於以下選項的反饋。我正在使用的場景涉及記錄一個項目是否運送到現有地址或新的地址。布爾型與更具體的變量

這兩種設置都會得到滿意的結果，但是他們的優點和缺點我沒有想到，或者哪些比較好？

field name: ship_to 
     option 1: new_address 
     option 2: existing_address 

Pro: 
- Allows for new options down the road if needed. 
- Easier to grasp what's going on when looking just a the database 

Cons: 
- Not easier to grasp in the code - have to remember the options 



    field name: ship_to_new_address 
     option 1: true 
     option 2: false 

Pros/Cons - Pretty much the opposite of what I listed above.

來源

2011-06-11 Susan

選項很容易記住 - 做出明智的'N'（新），'E'（現有）。如果需要，FK表（如果有）可以包含完整的「名稱」。該代碼在使用的語言中也將這些編碼爲常量。 '字符串NewAddress ='N''或其他。 – 2011-06-11 18:03:14

還有第三個選項：在自己的表

了地址（可能與owner列鏈接回你的用戶/帳戶表）。使用ship_to列與外鍵指向地址表。

優點：

，因爲他們需要（在家中，辦公室，山寨，朋友......）每個人可以有很多的地址。
很好標準化。

我唯一能想到的是你必須做更多的連接，但連接並不是一件壞事。你可能需要更多的理智檢查，以確保所有的所有權排列很好，但這也沒什麼大不了的。

來源

2011-06-11 18:14:31

業務需求是什麼？您是否試圖指出送貨地址已更改？你想區分新地址還是現有地址？

那麼，你爲什麼在意？你必須指出，如果新的地址保存到數據庫中？您需要報告運送到不存在地址的人數？

最後，你可以結束超過2個選項（新的，現有的）？

問題的答案將指示正確的方向。如果只有兩種選擇，我個人的偏好是使用布爾值，並且我認爲不需要擴展。但是，我處理很多外部API，所以改變需要更多的思考，而不是僅限於內部的選項。枚舉（通常會作爲「類型表」存儲在數據庫中）非常高效，性能卓越，而且在存儲中不會太重，所以它不是一個糟糕的選項。

來源

2011-06-11 18:07:44

答案既不是。

您提到的數據庫，我將假設意味着關係數據庫管理器。您的設計不遵循one-zero-infinity規則，並且需要進行修改才能在儘可能少的方便時間支持另一個送貨地址（例如當客戶尖叫時）。

合適的數據結構爲：

客戶有無窮大的訂單
訂單有收貨地址
還有的送貨地址無限數量

其中Customer，Order和Ship-To都是獨立的數據庫表。這就是所謂的Third Normal Form，並且自1970年以來一直是標準做法。

如果您需要注意訂單具有非標準的發貨地址，請在訂單中記錄該布爾值。

來源

2011-06-11 18:12:46 msw

有趣的東西。更多細節可能會對此採取反應。該任務實際上是記錄一個Return實例。鑑於此，在一零無窮規則中，替代地址總是「一」。感謝您的鏈接 - 良好的閱讀。 – Susan 2011-06-11 18:39:05

訂單有多少是返回實例？我可以想象它們非常相似，並且變化很小。客戶可以通過多個訂單項進行多次退貨嗎？這些如何代表？如果您已經在回程＃1上「燒」了新的送貨地址，那麼如果回程＃2去其他地方，您將會遇到困難。很容易說這種「不會發生」，但他們傾向於一旦你的設計使它不可能代表。 – msw 2011-06-11 20:18:45

這一切都取決於你想要完成的。如果你只想知道物品是否被運送到一個新地址，或者不是布爾值是OK的話。

我認爲你需要考慮如何讓你的架構可擴展。就像你在第一個「專業版」中所說的那樣，你可能想要有更多選項，例如「temporary_address」。如果你想要更多的確定性變量，你總是可以使用枚舉。

來源

2011-06-11 18:12:52 refaelos

布爾型與更具體的變量

回答

相關問題