I’m making a scheduler… i have a table of scheduled and scheduleable
hours for multiple users which needs to be turned into a view (with
schedule type as there are 4 different types) of 7 days of those
scheduled and scheduleable hours for multiple users…
right now i’ve a loop which iterates over every hour and tests it
against all the returned scheduleable and scheduled hours for those 7
days…
it’s really slow… the loop that figures out the schedule type runs like
1000 times and just obliterates my processor locally while it’s running.
anyone have any suggestion of how to speed things up? i’ve been
thinking about it but can’t seem to come to a speedier conclusion.
against all the returned scheduleable and scheduled hours for those 7
My suggestion is to drive things from the view requirements. What does
your view actually need to output? From there, work backwards to the
code required.
against all the returned scheduleable and scheduled hours for those 7
My suggestion is to drive things from the view requirements. What does
your view actually need to output? From there, work backwards to the
code required.
6:00 7:00
name0 b b r r r b r b b r b
r
name1 b b r r r b r b b r b
r
name2 b b r r r b r b b r b
r
name3 b b r r r b r b b r b
r
name4 b b r r r b r b b r b
r
name5 b b r r r b r b b r b
r
name6 b b r r r b r b b r b
r
this represents one of the 7 days and the type of schedule is determined
in a db table.
it’s basically just a calendar view from 8am to 12pm with colours for
each of the schedule types returned
so it’s a grid
Can you change the model then? It sounds like something easier done the
other way around, ie, you iterate through the things that are scheduled
for when they are scheduled, and get rid of the calendar in the model –
just implement it in the view based on the database of things scheduled.
hrmm. i guess it would make more sense to do a bunch of db querys and
parse small amounts of data instead of doing one big db call and parsing
large amounts of data… i’ll see if calms it down when it’s more
balanced.
hrmm. i guess it would make more sense to do a bunch of db querys and
parse small amounts of data instead of doing one big db call and parsing
large amounts of data…
No. Ask for all the records you need in as few queries as possible
(remember that AR will take arrays of IDs, as well as all manner of
other conditions). Many little queries is generally a sign that
something is wrong.
well say i had 25 users, i’d be doing 25 querys right. one for each
user then looping through the results in basically the same way i was
doing it before?
Gosh, I hope not. Fetch it all in one query with lots of joins, then
loop through the recordset in memory.
In general, DB queries don’t belong inside loops. Use the power of the
database instead!
hrmm. i guess it would make more sense to do a bunch of db querys and
parse small amounts of data instead of doing one big db call and parsing
large amounts of data…
No. Ask for all the records you need in as few queries as possible
(remember that AR will take arrays of IDs, as well as all manner of
other conditions). Many little queries is generally a sign that
something is wrong.
well say i had 25 users, i’d be doing 25 querys right. one for each
user then looping through the results in basically the same way i was
doing it before?
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Fetch it all in one query with lots of joins, then