NYCPHP Meetup

[inforequest]

csnyder chsnyder-at-gmail.com |nyphp dev/internal group use| wrote:

>On 3/29/06, csnyder <chsnyder at gmail.com> wrote:
>
>  
>
>>For any given day you generate a list of all the possible matches
>>(April 1, 2006 is a Saturday, an odd Saturday, first Saturday, first
>>of the month, etc), and then SELECT against those matches to find the
>>events that apply.
>>    
>>
>
>Sorry, just thinking about this, I think it's fair to point out that
>this is 30+ queries to render a month view, versus a system that
>doesn't allow recurring events and can pull all of the events that
>appear in a month with a single query.
>
>It's not that bad a thing, though. "I can do recurring events, but
>it'll cost ya."  ;-)
>  
>
I'm not ready to count queries.... I believe that's an artificial 
restraint that is really an accommodation of the business layer/logic. 
If we have good data, but the app needs a monthly calendar, doesn't that 
set a requirement for a subquery/temp table and then aren't there 
additional app-specific efficiencies likely to be available (generate 
monthly activity table for MAY; update if any MAY events changed, etc).

Perhaps this is exactly what I found distasteful about available 
"solutions"... they tied the business logic into the data storage too 
early in the game.