A few things to consider:
What is the required response time between be start of update transaction and availibilty of the updated result. If it's reaal time you may have slight issues here.
Is age defined with fine granularity or are we talking age groups? Age groups (if acceptable), would decrease the number of records signifficantly.
What database are you using? If it's one of those free MySQL versions then you are working with a pretty intensive processing. If you can switch to a database back end that supports stored procedures (Postgres, Firebird etc) then the time to update records will be cut down respectably.
The best way to see if the design you have in mind will be practical is to actually test it. Why don't you write a script (with whatever tools you are using) to:
1. create 250,000 records
2. run a batch update the records.
See how long #2 takes. Writing and running the test may be cheaper than a huge disappointment in case your design proves to be unrealistic.
Back to stored procedures: about a hundred years ago, when I still didn't quite grasp the benefit of a stored procedures, I run a similar test with Interbase DBMS. First run I ran a script to create 1,000,000 random records from the DB engine itself (using Delphi). I aborted after 50 minutes (about 40% of records were inserted). Then I re-ran the test but using stored procedures. This was successfully completed in 7 minutes. Based on that, and some other things I was able to learn along the way I would not even consider free MySQL versions for any semi-serious project.