简化：将计算字段与其余结果一起返回是否更好，还是在以后需要时更好地计算？
示例： 我有一个GridView显示搜索结果，其中包含许多字段：
等
帐号字段并不总是一致的。对于类型A的帐户，它们是八位数字，对于类型B的帐户，它们是十二位。
搜索后如果他们选择了一条记录并选择继续申请，我需要检查eigit数字帐号以了解任何访问限制。类型A和B的所有帐户都有一个关联的eigit数字帐号，只有B类是唯一拥有12位数字的帐号。
那么我应该在搜索结果中添加一个像“Common Account Number”这样的冗余隐藏字段，然后将其隐藏起来，从而使得频繁使用的搜索需要稍长时间并使结果网格在视图状态中占用更多空间？ / p>
或
我是否应该在尝试继续申请并将应用程序ID转换为eigit数字号码时调用数据库，以便我可以使用它来进行访问限制检查？这将需要对数据库进行一次额外调用，但转换应该很快，因为两个字段都在同一个表中，并且应用程序ID是主键。由于还有许多其他命令选项，因此将继续使用“继续”应用程序按钮。人们也更愿意等待处理某些事情，而不是等待搜索结果。
答案 0 :(得分：1)
您应该始终根据实际测量结果做出决定。我喜欢你尽可能快地制作最常用功能的原则。
但也许有一种方法可以立即返回正确的结果集 - 例如，您是否需要该显示中的8位数字，或者您是否可以立即返回12位数字B型账户？如果是，也许您可以定义视图，或者在数据模型中立即添加计算列。是否有另一种保存状态的方法，以便您可以避免隐藏的字段？
除此之外，你是能够衡量这个数字的人。如果“继续”操作比搜索更少见，并且如果不花费很长时间，那么，通过一切手段，添加另一个数据库往返。但是，如果你能够在不增加可测量延迟的情况下一步完成搜索，那就去做吧。
答案 1 :(得分：0)
添加额外的隐藏列没有问题，特别是如果您有内部公司应用程序。
但是，您是否也可以在存储过程中执行访问限制检查？也就是说，存储过程会将app id处理为八位数转换而无需额外的往返。然后，从存储过程中，您可以返回相应的错误或适当的结果集。