0

ORM として LLBLgen を使用しており、次のことを実現したいと考えています。

表 1 :
セッション ID


表2 : SessionId
タイムスタンプ

SELECT TOP 100 * FROM Table1
INNER JOIN Table2 ON Table1.SessionId = Table2.SessionId
ORDER BY Table2.Timestamp DESC

このコードは、SQL Server 2008 R2 で直接実行すると正常に実行されます - 可能な場合は Table1 から正確に 100 行を返しますが、どういうわけか LLBLGen で同じ結果を得ることができません。現在、私はまだ 2.6 を使用していますが、必要に応じて更新することもできます。

LLBLGen でこの動作を実現する可能性はありますか?

これは、LLBLGen で通常のメカニズムを使用した場合の結果です

SELECT * FROM Table1
INNER JOIN Table2 ON Table1.SessionId = Table2.SessionId
ORDER BY Table2.Timestamp DESC

ところで: LLBLGen がリーダーから上位 100 件の結果を取得し、接続を切断することを読みました。それにもかかわらず、クエリは、SQL を直接実行する場合と比較して、LLBLGen を使用する方がはるかに時間がかかります (これは、驚いたことに、後者のクエリにも当てはまります!)

4

1 に答える 1

1

It doesn't add TOP as that would maybe return duplicate rows as you have a join and there's a situation in your query (you didn't post the real query) where you have distinct violating typed fields in your projection.

In general, when fetching entities, llblgen pro will add TOP in your case and DISTINCT. If it can't add distinct, because your query returns fields of type image, ntext, text, or you sort on a field which isn't in the projection (so distinct can't be applied otherwise sqlserver will throw an error), it won't add TOP either as that could mean you get potential duplicate rows in the set limited by TOP, which are filtered out, as entities are always unique.

Example: fetching Customers based on a filter on Order (so using a join), will create a Customers INNER JOIN Orders on northwind, but as this is a 1:n relationship, it will create duplicates. If Customers contains a text, image or ntext field, distinct can't be applied, so if we then would specify TOP, you'll get duplicate rows. As llblgen pro never materializes duplicate rows into entities, you'll get less entities back than the value you asked for.

So instead it switches, in THIS particular case, to client side limitation: it kills the connection once it has read the # of entities (not rows!) which you asked for. So if you ask for 10 entities and you have 10000 duplicate rows in the first 10010 rows, you'll get 10000 rows being fetched at least.

So my guess is the sort on table2 which is the issue, as that prevents DISTINCT from being emitted. This is an illegal query on sqlserver:

SELECT DISTINCT C.CompanyName FROM Customers C INNER JOIN Orders O on c.CustomerId = o.CustomerId ORDER BY o.OrderDate DESC;

The reason is that ORDER BY appends a hidden column for all fields to sort on which aren't in the projection, which ruins the distinct. This is common in RDBMS-s.

So TL;DR: it's a feature :)

于 2012-05-16T13:16:09.863 に答える