1) Use lazy if you want the object but don't necessarily want the rest.
2) Do you *really* want to load all those? General rule of
databases: Don't ask for more than you want to use. The fact that
you can do a thing isn't the same as whether or not you *should* do a
thing.
Personally? Build some OQL that loads the sub-records that you're
looking for - don't necessarily take the easy way out and map all
half a million records to the primary object.
For example:
- Customer record has a number of bills that are attached;
- Bills have a set of summary information which apply to them, and
have data rows which may number in the thousands.
Build a customer object with either calculated columns in the DB or
build the load as a stored procedure which, alongside returning your
data, returns summary information about the current state of the bills.
Build a bill object that, alongside an allRows() marked as "never use
me unless you're really sure" in
documentation in big, flashing letters, is loaded from a stored
procedure which generates the summary content;
alternately, store the summary content in the table through summary
rows and insert/update/delete triggers
to manage them (or just build a view or an indexed view of your
massive 'billing item' table, where the rows
in the summary table are aggregates of the data in the billing item
table).
Then build API in the bill object that allows you to load cross-
sections of the billing information; by month, etc.; in some cases,
it's even worth building in pagination into the API, so that you can
do multi-page results with minimal data loading - it depends on what
you're trying to accomplish.
Now, I'm not a DBA; nor do I play one on television. But you can't
tell me that your DBA would be happy with what you're proposing. :)
On 25 May 2005, at 03:01, PAUL CHAN NCSI HK NCS wrote:
Actutally, i find that the performance problem seems not related to
execution time of generated SQL.
i can grep the SQL (outer join.. all related tables) from the DBA.
I find
that the SQL return result quickly with many thousand of records..
but I wait over 10 mins for get back the Object instance from JDO....
so the bottleneck is at JDO side? how can i improve the performance
result?
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
