1

我们的项目有大约 40 个具有复杂关系的表。一位同事认为使用长连接查询强制我了解模块之外的表，但我认为我不应该关心与我的模块没有直接关系的表并使用数据访问函数（由负责其他模块的人编写）当我需要他们的数据时。让我澄清一下：

我负责 ContactVendor 模块，该模块使客户能够联系供应商并就某些特定产品展开对话。Products 模块有它自己的复杂表和与封装细节的函数的关系（例如 i18n、激活、产品可用性等......）。现在我需要显示一些与供应商和客户之间的对话相关的产品的产品标题。我可以编写一个长查询，一次性检索产品信息和对话内容（这迫使我了解产品表），或者我可以将相关的 product_id 传递给 get_product_info(int) 函数。

第一种方法显然要求很高，并引入了许多不良做法和我通常认为编程错误的事情。第二种方法的问题似乎是这些访问函数导致的无数迷你查询，当循环尝试使用每个执行单独查询的函数来获取 100 个产品的产品标题时，性能损失是一个问题。所以我被困在“不要对实现编码，对接口编码”和性能之间。什么是正确的做事方式？

更新：我特别担心将来可能对我的模块之外的这些表进行修改。如果产品模块决定改变他们做事的方式怎么办？或出于某种原因修改架构？这意味着其他一些模块会损坏或出现故障，直到将更改集成到它们中。通常的涟漪效应问题。

4

3 回答 3

1

我可以看到问题的两面。但是，鉴于您说只有大约 40 个表，在我看来，与您专业领域之外的其他 30 个表进行交互的复杂性是最小的。我会投票支持编写执行复杂连接的查询。毕竟，除了知道表中的确切列（这应该很容易）之外，您真正需要知道的只是这些表使用的任何特殊关系或特殊含义。

但另一个可能为我做出决定的事实是性能要求是什么？如果系统当前足够快，并且硬件和表大小仍然足够快，对每个表使用单独的查询仍然足够快，如果它使每个人的生活更轻松，请继续使用第二种方法。但是另一方面，如果有人曾经抱怨过速度，或者将来可能会无限制地增长表，或者您的用户数可能会增加，请使用最有希望的方法进行处理快点。

回应评论：不必要。假设产品模块添加了 5 个新列。要么您还没有使用它们，因此没有加入或检索它们，并且无论您选择哪种方法都不会受到影响，或者您需要它们并且必须编写新代码来处理它们。无论如何，无论您选择哪种方法，对您的更改都将是相同的。假设产品模块重命名或删除了 3 列。然后你的一方将不得不改变它处理返回值的方式，而与接口的编写方式无关。我明白您的意思，但最重要的是，恕我直言，如果您使用更改中涉及的字段，则必须更改代码。如果您不使用这些字段，则不使用。如果您只获取所需的列，而不是使用select * from tbl查询。

于 2010-06-18T11:56:38.293 回答
1

在这里使用视图怎么样？

不要调用 get_product_info 函数，而是让每个模块维护者提供该模块的视图，例如 product_info_view，然后将此视图用于您的查询。像这样，您不必担心此类视图的内部结构（表），但仍将获得性能优势，因为数据库引擎将简化包含您的代码和视图的最终查询。

于 2010-06-18T12:24:37.067 回答
1

Martin Fowler 在他令人惊叹的著作《企业应用程序架构模式》中很好地描述了做这类事情（持久性/数据源/ORM）的正确方法。这本书是企业发展中每个人的必读之书。

于 2011-01-20T07:16:29.320 回答