5 ms·
Going to have to ask for an example. I am yet to have seen a basic CRUD app that had performance issues due to a bad coding algorithm. Certainly from poor quer
by boyter 13y ago
Going to have to ask for an example.
I am yet to have seen a basic CRUD app that had performance issues due to a bad coding algorithm. Certainly from poor queries but never from an bad algorithm.
Keep in mind I would say that a simple CRUD app with millions of entries is no longer a simple CRUD app.
- yuliyp 13y agoWhat does "poor queries" mean other than queries with poor asymptotic complexity based on the query plan?
- boyter 13y agoDoing something like the following would classify as a poor query in my book with a very simple query plan, select * from table;
- yuliyp 13y agoThe query plan for that is simple, but the number of bytes transmitted per query is O(size of table) (as is the disk IO on the DB), which should clearly set off a red flag if you know that size of table can get large. You don't need a large exponent; You need to understand the rough cardinality of values, then you need to look at asymptotic complexity.
- mseebach 13y agoSo, the problem with your exclusion of "non-simple CRUD apps" is that simple CRUD apps have a nasty habit of ceasing to be simple. But yeah, case in point: I ran a small BB-style web forum a number of years ago. As it grew larger (on the order of 10k posts - hardly earth shattering for a web forum), the load on the server got unsustainable, and the page loads were really slow. It turned out that the algorithm to decide if a user had seen a post was to maintain a list of seen post IDs for each user, and compare them at each page view. For active users, the number of seen posts obviously approaches the number of posts: n^2.
- brown9-2 13y agoA very easy, common example: given two lists of objects (from a database most likely), find the set of objects contained in both lists. The naive solution is a double for loop over each collection.