The problem is that even in your scenario, it make no sense to do it in this way. If I need to load that much data, I would use stateless session, for example, issue two queries (component and sub component), and maybe resolve the association manually. It should all be done in about as fast as the DB can serve the data.
That is the problem with those types of benchmarks, and the reason that you see so many people objecting to them. Without context, there is no meaning to the question. On Thu, Feb 12, 2009 at 1:38 PM, Chucara <[email protected]> wrote: > > Gustavo: > > I agree, but given our scenario, this test is very relevant. But it is > not the only foundation for our decision. We are planning on doing > bulk load with stored procedures (where necessary), but that is not an > option that is not available to us in EF, as the EntityObjects are > slow to work with. More specifically, this operation: > ClassA.PropertyOfTypeClassB = new ClassB(); is extemely slow on EF, > which rules out the SP/ADO option. > > Again, that test was one of out several, and we need to be able to > manage large quantities of data if a customer requests it. For 99.99% > of the case, it'll be few rows, but it should still be technically > possible (within a reasonable time) to load 100,000 rows if the > customer wants it. Given that NH can load 110,000 rows in 30 seconds, > NH meets our requirements. >
