in reply to Finer points of Class::DBI
Under the has_a and has_many sections of the docs, there is one called limit, which explains how to get results that are limited.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Finer points of Class::DBI
by dba (Monk) on Sep 14, 2004 at 00:19 UTC | |
| [reply] |
by jreades (Friar) on Sep 14, 2004 at 11:55 UTC | |
Yeah, some more details on the db architecture would be very useful since this seems like more of a query issue than anything else. While I can envision a number of ways that an area would have a 1..n relationship with the statistics, I'm just going to have to guess at the field layout (note, I'm not even getting into normalisation):
-------------------- --------------------
| Areas | | Stats |
-------------------- --------------------
| PersonId | | PersonId |
| Person | | Person |
| Group | | Stat |
-------------------- | MonthKey |
--------------------
Assuming that your setup looks anything like this, then there are several ways to query this table for an ordered list of stats. If you wanted everything ordered by date (so no rollup) it would be:
If you wanted to get a date range it would be:
And so on. The output from this query would be quite easy to work with in Perl because you can run through the output without worrying about order:
Hope that helps -- it was a bit of a speculative jump based on the available information, but dbs are designed for querying, sorting, and ordering in clever ways that require you to be a true programming god to reproduce in Perl with anything like comparable performance. | [reply] [d/l] [select] |
by rlb3 (Deacon) on Sep 14, 2004 at 13:24 UTC | |
Hello thanks to all who helped. I guess I skipped over the section on limiting has_many in the docs. That was what I needed. Some of you have asked for the make up of my tables and which database I'm using. Database: mysql 4.0.21 Tables:
Again, thank you for your help. rlb3 | [reply] [d/l] |
by cleverett (Friar) on Sep 14, 2004 at 06:24 UTC | |
Moral: use CDBI where reusability, portability and ease of coding take a priority over performance (almost everywhere). Use hand coded SQL and DBI when you need to sacrifice everything for speed. | [reply] [d/l] |