Bottom line point, the general "feeling" of that page is to dissuade people from even CONSIDERING using SQLite for future enhancements (Considering the age of that page). I won't get on board with that.
What I meant by "common sense" is more towards the hardware the software is going to be used on. A desktop PC running Win7 with 32k or 64k cluster sizes via NTFS on a platter drive of any RPM is going to operate a LOT differently than an 4k to 8k cluster sized SD card formatted either at FAT32 or EXT3 on a phone or tablet, when we're talking about the nuts and bolts and welds that hold the machine, OS, and software together. Different latencies between OS and storage medium (Forget the software making the calls at this point) SHOULD drive the "optimization" development towards "platform particular" configurations. None of that has anything to do with SQLite in itself. And when SQLite does enter the picture for optimization, a really basic check is to look at the OS the software is running on to find out what kind of file system it might be writing to, then create/regenerate the database paging system based on a "best guess" cluster size, or have a pre-built matrix to indicate what 'normal' drive configurations are and build the database against what that matrix says works well. That is only ONE aspect that can SERIOUSLY decrease IO waits. Basically, my impression of most of that page, which the information contained within is absolutely correct IMO, is that they're targeting mostly the wrong foundation. I know that it is a page of "Things to watch for" but targeting SQLite itself.. well.. I feel that the author is looking through the wrong looking glass. On Sun, Jun 14, 2015 at 11:57 AM, Scott Robison <scott at casaderobison.com> wrote: > On Jun 14, 2015 9:43 AM, "Stephen Chrzanowski" <pontiac76 at gmail.com> > wrote: > > > > Most of that looks to be more like common sense things rather than SQLite > > specific, so why they're calling out SQLite, I've no idea. Also, this > doc > > was last modified more than a year ago. Stuff has changed both within FF > > as well as SQlite since then. > > They call out SQLite because that is the engine they embed in their > infrastructure. They aren't worried about people in their code base trying > to use MySQL, PgSQL, SQL Server, or Oracle. They're worried about their > developers using SQLite when some other format would be more appropriate > for some fuzzy value of "appropriate". > > One shouldn't use a hammer on screws or a screwdriver on nails. Use the > right tool for the job. Sometimes FILE* based functionality is the right > tool. Sometimes not. It all comes down to the fuzzy concept of appropriate. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
