5
Running a scheduled task to perform updates in your game, at any interval, will give you a spike of heavy database use. If your game logic relies on all of those database values to be up to date at the same time (which is very likely, if you’re running an interval based update), you’ll have to have scheduled downtime for as long as that cronjob is running. When that time becomes longer, as your player base grows, this becomes extremely annoying.
If you’re trying to reduce database overhead, you should store values with their last update time and growth rates, and only update those rows when the quantity or rate of growth changes.
For example, a stash of gold, that grows at 5 gold per minute, only updates when a player withdraws gold from it. When you need to know the current amount, it is calculated based on the last update time, the current time, the amount stored at the last update, and the rate of growth.
Data that changes over time, without requiring interaction, does not belong in the database. It belongs in the logic end of your game. When a player performs an activity you need to remember, or a calculation becomes too cumbersome to generate again, that’s when you store it.
2
If I understand your question correct, you should look at Celery which is a distributed task queue. http://ask.github.com/celery/
- [Django]-Getting 404 error when loading bootstrap based homepage in Django
- [Django]-Stream videos from Django application
- [Django]-Using reverse relationships with django-rest-framework's serializer