数据设计——多次短途旅行与一次大旅行答案

【问题标题】：Data design - multiple short trips vs one big trip数据设计——多次短途旅行与一次大旅行
【发布时间】：2011-03-18 15:19:39
【问题描述】：

归结：将计算字段与其余结果一起返回更好还是稍后在需要时计算更好？

示例： 我有一个显示搜索结果的 GridView，其中包含许多字段，例如：

应用程序 ID
姓名
帐户类型
帐号

等等

帐号字段并不总是相同的东西。对于 A 类帐户，它们的长度为 8 位，对于 B 类帐户，它们为 12 位。

搜索后，如果他们选择记录并选择继续申请，我需要检查 eigit 数字帐号是否有任何访问限制。 A 和 B 类型的所有帐户都有一个关联的 eigit 数字帐号，只是 B 类型是唯一具有 12 位数字的帐号。

那么我是否应该在搜索结果中添加一个像“通用帐号”这样的冗余隐藏字段并将其隐藏，从而使大量使用的搜索花费稍长的时间，并使结果网格在视图状态下占用更多空间？

或者

当他们尝试继续应用程序并将应用程序 ID 转换为 eigit 数字时，我是否应该调用数据库，以便我可以使用它来进行访问限制检查？这将需要对数据库进行一次额外的调用，但转换应该很快，因为两个字段都在同一个表中，并且应用程序 ID 是主键。由于有许多其他命令选项，继续应用程序按钮的使用将减少。人们也更愿意等待处理某事而不是等待搜索结果。

【问题讨论】：

你为什么要问我们？您知道（或将知道）这些更改将产生多大的影响并知道如何进行。我们的意见有点无关紧要。
只是想知道别人的想法。我对统计感兴趣，并了解我周围的世界。因为我已经实施了一个解决方案，所以我不一定会接受任何指导，但我认为我正在寻求的知识是有价值的。

标签： asp.net database-design architecture performance

【解决方案1】：

您应该始终根据实际测量结果做出决定。我喜欢你尽可能快地制作最常用功能的原则。

但也许有一种方法可以立即返回正确的结果集 - 例如，您是否需要该显示中的 8 位数字，或者您是否可以立即返回 12 位数字B类账户？如果是，也许您可以定义一个视图，或者立即在您的数据模型中添加一个计算列。有没有另一种保存状态的方法，这样你就可以避免隐藏字段？

除此之外，您是能够衡量这一点并拥有数字的人。如果“继续”操作比搜索少得多，并且不需要很长时间，那么无论如何，添加另一个数据库往返。但是，如果您能够在不增加可测量延迟的情况下一步完成搜索，那就去吧。

【讨论】：

该字段必须根据业务规则在 eigit digit number 和 12 之间切换。老实说，这是有道理的，但也很难提供优雅的编码解决方案。

【解决方案2】：

添加一个额外的隐藏列没有问题，特别是如果您有一个内部公司应用程序。

但是，您不能在存储过程中也进行访问限制检查吗？也就是说，存储过程将处理应用程序 id 到八位数字的转换，而无需额外的往返。然后，从存储过程中，您可以返回适当的错误或适当的结果集。

【讨论】：

访问限制必须通过一个 Web 服务调用来检查多个系统，并且绝对需要 eigit 数字来完成所有工作。