On Mar 4, 2:05 pm, AD7six <[email protected]> wrote: > > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
