> > When I mentioned aMySQL viewto solve the problem of calculated
> > columns, you replied:
> > > This is called de-normalization, and is a very common thing to want to
> > > do, for many reasons, including but not limited to performance
> > > improvements and reducing code complexity.
> > For what it's worth, creating aMySQL Viewto join the two and include
> > calculated columns is not de-normalization.
>
> You're quoting out of context/sequence and possibly missing the point.
You're right. My mistake. However, my point is still valid as I
believe Nate originally incorrectly considered calculating pseudo-
columns in the model
s afterFind method "de-normalization".
> In what way would using a view (if you choose) or using
> counterCache fields for each of your agregate fields, or a stock left
> join, group by and agregate function, NOT solve your question?
Everything you mention is sufficient, except using counterCache. I
was trying to get a sanity check to make sure I wasn't bypassing some
already existing piece of Cake. Since it seems the community is
divided when it comes to using views/functions in the database or
using a custom query (really the same thing) I wanted to see if there
really is a Cake way to do what I want.
De-normalizing would certainly allow me to search and sort as I
described. I know counterCache can be used to populate a
voicemails.transcription_count column, but I don't know that I can use
it to populate something like
voicemails.transcribed_transcription_count or a boolean
voicemails.has_blank_transcriptions, can I? Maybe that is the purpose
of counterScope, which does not appear to be documented at
book.cakephp.org. I'll check into Cake's core and unit tests to see
if it would do the trick.
De-normalizing also does not support a calculated column that depends
on a point in time. For instance if a transcription can be locked for
15 minutes, and that 15 minute window passes, a
voicemails.locked_transcription_count column is not instantly (or
ever) updated. The best you could do is set up a cron job to manage
these, which is not clean. A view with a calculated column (like
DATEDIFF with SYSDATE) handles all of this by trading off a bit of
read-time performance. I think this trade off very much outweighs the
cost of development complexity to manage de-normalizing data.
Thanks all for the help. But given my situation, and the lack of
another clear solution that will solve every challenge I've noted, I
think creating a view is going to be the best option.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "CakePHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to cake-php+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---
No comments:
Post a Comment