Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
A fully normalized database with no redundant data is good “academically”, but has terrible real-world performance.
The first optimization is obviously a cache system. After this, for creating redundant data for performance, when or why would (or wouldn’t) you use triggers over a cron task that calls a script to update the redundant data?
Not a MySQL guy, but the concept should port…
Basically, a cron job is a scheduled job (however frequently you want that run), and a trigger is… well… triggered. In general, you would use any kind of scheduling (Cron, scheduled jobs (in the MS Sql world), etc.) when the task you want is one or both of:
* Not Time Sensitive
* Process Intensive.
For anything that is time sensitive and not process intensive, you’d use a trigger.
For those cases where something is both time sensitive and process intensive, you have to decide which is more important (or handle the crunching outside of SQL in code somewhere).