Trying to address a request from my team that would essentially double to quadruple the number of tasks we have attached to our shots; the idea is to circumvent the need for directors/supervisors to create their own new tasks, and just have all possible tasks added by default. (i.e. if have a revision phase, we include revision tasks for all departments, even if we eventually don’t need them).
Aside from severely cluttering up task views in general, would we (eventually) have to worry about speed degradation across our ShotGrid site? Whether it’s query fields dealing with tasks, or just navigating around that project?
on a typical project, that could mean half a million tasks associated to shots alone.
I could see a potential workflow of, once a section is finaled, we cull any unused tasks, to try and keep the environment free of redundant/unused tasks, which could be viable for our workflow, but was wondering if anyone had any insight as to whether ShotGrid was up to the “task” in this regard, when it comes to high volumes in a single project.
Its a database, the more queries you do and the more results are in those queries affects the performance. Not necesarily the size of the database (not entirely true but querys are where the slowdown occurs mostly).
ShotGrid runs on AWS so the database should hopefully scale with the site.
Thanks for the insight, Ricardo. I’ll keep this in mind, and try to do a bit of testing.
Yeah, we’re in the animation stream; the team is used to less involved/customizable software, so on the one hand, ShotGrid has given them a taste of what it’s like to have plenty of options, but also means being careful with the initial planning during these adoption phases.
It should be able to handle these things, this is why SG has page record limits.
And Query Fields are not always the best choice, sometimes its better to run a event daemon and have that update fields with information or calculations.
Yeah, I’ve already noticed that with the query fields; they’ve been useful to display info during the adoption phase for easy access, or as temporary solutions, but I’ve already started replacing these with stored values created by event daemons, since you can do so much more with that data (filtering, formatting, grouping, etc…)