> More generally, I *often* see good C++ programmers pushing application > logic into SQL, and getting it wrong because they don't really know > SQL. As a result, my rule of thumb is to make the separation between > application code and SQL code based on whether the code is filtering > result sets. If the code reduces the number of results, it probably > should be in the SQL, but if it just processes the results without > removing any rows, it should probably be in application code. In a > client/server system like MySQL, it can sometimes be worthwhile to > additionally have the server do operations which reduce the physical > size of the individual results (say taking a substring of a column), > but for SQLite that is seldom worthwhile (application code can make > better targeted decisions about memory allocation and the like). > > Since SQLite is running in-process, communication is cheap, so it is > also often the case that there is no particular performance gain from > having SQLite do calculations rather than your application code. > SQLite can probably optimize SELECT COUNT(x) better than your > application code can, but SELECT MAX(x) would probably be about the > same performance if implemented in application code.
Truth. And I like the rule of thumb, but only in cases where you are in-process, or, at a minimum, in-machine. Sometimes you need to crunch a really large number of records and the cost of transmitting them to an application program is prohibitive. Marc _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
