一种创建多个对象的方法或几种创建单个对象的方法?

时间:2008-09-16 12:03:50

标签: .net database performance

如果我有以下内容:

Public Class Product
    Public Id As Integer
    Public Name As String
    Public AvailableColours As List(Of Colour)
    Public AvailableSizes As List(Of Size)
End Class

我希望从数据库中获取产品列表,并在页面上显示它们的可用尺寸和颜色,如果我

  1. 有一个方法(GetProducts()),它使用一个连接相关表的视图,然后遍历每一行并根据需要创建对象?或...
  2. 有几种方法只负责创建一个对象?例如。 GetProducts(),GetAvailableColoursForProduct(id)等
  3. 我正在做一个)但是当我添加其他其他属性(多个图像,可选的流苏等)时,代码变得非常混乱(必须检查这与前一行不是同一产品,已经这种颜色已被添加,等等)所以我很想去b)然而,这将真正增加到数据库的往返次数。

8 个答案:

答案 0 :(得分:1)

你明白了。解决方案b不会扩展,所以解决方案是关键,只要性能受到关注。同时,为什么要限制GetProductDetails()方法来获取单个请求中的每个数据(因此采用SQL视图方法)?为什么不让这个方法执行3个请求并告别乱糟糟的逻辑:

  • 一个用于ID和名称检索
  • 一个用于颜色列表
  • 一个用于尺寸列表

根据您使用的SQL引擎,这3个请求可以分组在一个批处理查询中(一次往返),或者需要3次回合。向班级添加其他属性时,您必须决定是增强第一个请求还是添加新请求。

答案 1 :(得分:1)

你可能最擅长对两者进行基准测试并找出答案。我已经看到只做多个查询(MySQL喜欢这个)的情况比JOIN更快,一个大的慢查询需要大量内存并导致数据库服务器崩溃。我说基准测试因为它取决于你的数据库服务器,它有多少内存和并发连接,表的大小,索引的优化方式以及典型记录集的大小。大型无索引列上的JOIN非常昂贵(因此您应该不执行它们或添加索引)。

如果您至少编写两个实现(您不需要编写方法,只需要一堆测试查询)然后进行基准测试,您最后可能会学到更多/更满意而不是只与一个或另一个去。测试中最棘手(但很重要)的部分是模拟并发用户同时访问数据库 - 真实的生产内存和CPU负载。

请记住,您正在处理两个问题:一个是DBA问题,如何使其最快,最有效。第二个是需要漂亮,可维护代码的程序员。 (b)使代码比具有复杂JOIN的巨型查询更具可读性和可扩展性,因此您可以决定优先于(a),只要它不会非常慢。

答案 2 :(得分:0)

就个人而言,我会通过更少的方法从数据库中获取更多数据,然后将UI仅绑定到我当前想要显示的数据集的那些部分。管理大量获取特定数据块的小方法比获取大块数据并仅使用您需要的那些部分更难。

答案 3 :(得分:0)

在上面的例子中,我可能只有一个静态加载方法,特别是如果通常需要所有或大部分属性:

Public static function Load(Id as integer) as Product

Product.Load(Id)

如果说颜色属性很少使用并且加载相当昂贵,那么你可能仍然想要使用上面但不从那里加载颜色属性但是从getter动态加载它,如下所示:

private _Colors as list(Of Color)
public property Colors() as List(Of Color)
    get
        if _Colors is nothing 
            . .. . load colors here
        end if
    end get. . . . .

答案 4 :(得分:0)

转到选项b)它使您的属性独立于数据表示(例如表格)

我认为您可以从了解MVC-Architecture的更多信息中受益。它代表 M odel(您的数据 - >产品), V iew(演示文稿 - >表)和 C ontroller(a将从模型中收集数据并为View输出处理它的新类

困惑?它并不复杂。您的代码片段来自哪种语言?像Ruby on Rails,Java Struts或CakePHP这样的许多框架都实现了程序层的这种分离。

答案 5 :(得分:0)

在阅读您的设置时,

b会更快(性能明智),但是当您更新课程(更新每个功能)时,它将需要更多维护代码。

现在,如果表现是你的真正目标,那就做基准吧。写下a和b,用几(数百)千条记录加载你的数据库并进行测试。然后选择最佳解决方案。 :)

/维伊

答案 6 :(得分:0)

如果您在编码实践中使用任何敏捷租户,那么“a”现在就可以了,但随着查询复杂性的增加,您应该考虑重构,即根据您现在所知道的内容构建代码。必要时重构。

如果您进行重构,我建议您在代码中引入factory pattern。工厂模式管理复杂对象的创建,并允许您从使用该对象的代码(在本例中为您的UI)中隐藏对象构造的详细信息。这也意味着当您的对象变得更加复杂时,将保护消费者免受您为管理复杂性而可能需要进行的更改。

答案 7 :(得分:0)

您应该查看Castle的ActiveRecord ORM,它在NHibernate之上。您开发了一个数据模型(就像您使用'Product'一样),它继承自AR的基类,提供了很好的查询功能。 AR / NHibernate提供积极的查询优化和缓存。性能和可伸缩性问题可能会消失。至少你有一个适当的框架可以调整。您可以轻松地将数据模型拆分为测试B.