數據設計 - 多次短途旅行與一次大行程

Question

明確：將計算的字段與其餘結果一起返回還是更好地在以後需要時計算它會更好？

例子： 我有一個顯示，有許多領域，如搜索結果中的GridView：

• 應用ID
• 名稱
• 帳戶類型
• 帳號

等

儘管賬號數字並不總是一致的。對於A型賬戶，它們是八位數字，對於B型賬戶，它們是十二位數字。

搜索後，如果他們選擇了一條記錄並選擇繼續申請，我需要檢查任何訪問限制的eigit數字帳號。類型A和B的所有賬戶都有一個關聯的eigit數字賬號，只是B類型是唯一擁有十二位數字的賬號。

因此，我應該向搜索結果中添加一個類似「Common Account Number」的冗餘隱藏字段，並將其隱藏起來，從而使大量使用的搜索花費更長時間，並使結果網格在視圖狀態中佔用更多空間？

或者

我應該調用數據庫，當他們嘗試繼續應用程序和應用程序ID翻譯成eigit位數，這樣我可以用它做我的訪問限制檢查？這將需要一個額外的數據庫調用，但翻譯應該很快，因爲兩個字段都在同一個表中，並且應用程序ID是主鍵。由於有很多其他命令選項，繼續應用程序按鈕的使用將會減少。人們也更願意等待某件事來處理，而不是等待搜索結果。

Answer 1

您應該始終根據實際測量結果做出決定。我喜歡儘可能快地製作最常用功能的原則。

但也許有立即返回正確的結果集的方式 - 例如，你需要在顯示的8位數字，或者你能立即返回12位號碼爲B型賬戶？如果是，也許你可以定義一個視圖，或者在數據模型中立即添加一個計算列。是否有另一種拯救狀態的方式，以避免隱藏字段？

除此之外，你可以衡量那個人，誰是數字。如果「繼續」操作比搜索更加罕見，並且如果不需要很長時間，那麼通過一切方式，再添加另一個數據庫往返操作。但是，如果您能夠在不增加可測量的延遲的情況下一步完成搜索，那就去做吧。

Answer 2

添加一個額外的隱藏列沒有問題，特別是如果您有內部公司應用程序。

但是，您是否也可以在存儲過程中執行訪問限制檢查？也就是說，存儲過程會將應用程序ID轉換爲八位數轉換而無需額外往返。然後，從存儲過程中，您可以返回相應的錯誤或適當的結果集。