3 ms·
The third side of the coin: * How many processes aren't executed more often because they are inconvenient? How much less efficient does this make the org? * H
by bitcurious 7y ago
The third side of the coin:
* How many processes aren't executed more often because they are inconvenient? How much less efficient does this make the org?
* How much is index fear driven by 20th century hardware cost?
Anecdata:
In a prior job, I worked at a nonprofit that partially shares a CRM codebase with another ~30 peers. I cut query runtime 10x with a few indexes. I cut query write-time similarly by writing a few denormalized SQL views. The cost on CRUD transactions was marginal.
These queries drove mailings, marketing efforts, financial reporting, PowerBI dashboards, etc. Our peer organizations that used the out-of-the-box query tool favored SSRS reports for the same functionality, which meant that reporting was less flexible and more expensive to maintain. I can't prove causality but I believe query ease-of-use made a big difference.
- tracker1 7y agoLikewise, I recently had a "discussion" with a colleague and their contention was that they had too many writes for an SSD to be reasonable (they don't)... However, still complaining about performance in their app. Every time you want 10x the users, you need to make compromises in design to reach that goal... 100 users is easy, 1000-10000 you can hardware your way out. More than that, your design better be decent.
- flukus 7y agoSo many performance problems I see with database writes are developers not understanding implicit transactions, they think transactions equate with more work and don't realize how much processing and disk writing can be saved by not having to update indexes on every insert. I've lost count of the number of times I've seen transactions reinvented with staging tables too. I suspect this contributes to a lot of the fear about indexes creating performance problems too. IME if you've got less than 100GB of data (maybe more on SSD) then correctly using indexes, joins and transactions will solve 90+% of performance problems and most things will be quite snappy without much tuning.