Quote:
Originally Posted by AdamHeard
We run a VERY large gdocs based scouting system, that is doing a lot more than just averaging (such that when data is entered, a lot recalculates).
Even with this, it runs. I suggest you look into what runs fast/slow on gdoc, and thoroughly understand the process it uses when to update cells. Short answer is anytime cell A changes, every cell that references it upates, and that cycle repeats.
Don't use vlookups. At all. Even once. Just don't do it. Use index(match()) instead. Google it for good tutorials, this doesn't load the range per each cell called. Importrange/sortrange can also be used where vlookup would be used by some people with better results. More or less, don't use vlookup and don't use cell by cell calls to pass entire ranges if you can help it.
If you want me to take a look at your system and offer more specific advice I can. I'm not saying this to criticize you guys, but I'm 100% sure the issue here is implementation, not google docs.
|
Not to criticize, honest question - If you're already doing VLOOKUP and INDEX type operations why not invest a little bit of time to learn how to do this stuff with a full blown relational database? It'd be faster performing, more scalable, more reliable, and teach students useful skills. I guess the only real issue would be a simple front end but that's not that bad to do any more…
Disclaimer - my bread and butter is databases, Postgres, SQL-Server, Mongo, CouchDB… When all you've got is a hammer every problem looks like a nail, I'm genuinely curious why so many people seem to shoehorn excel into a job for an actual DB.