On 2015-09-17 04:50 PM, John McKown wrote: > On Thu, Sep 17, 2015 at 9:41 AM, R.Smith <rsmith at rsweb.co.za> wrote: > >> (11) This forum. Need help or suggestions with how to optimize your >> internal value-store? Not so easy. Need help optimizing an SQLite DB or >> query? We've all seen the very clever people here always eager to assist. >> It's an amazing and very valuable resource. (This one is also true for >> other community-supported DB systems in general) >> >> >> Cheers, >> Ryan >> >> > ?OK, I did really put my foot in it. [grin/]. I do that often enough to not > be upset by it. But it did result in the OP doing a test and realizing that > the problem was _not_ data access, but apparently elsewhere in the code. > I'm a bit of an pro-SQL person myself. Especially when doing things which > require joins & CTEs! I trust the SQL people's code a lot more than I trust > my own (I'm a sysadmin who can program, but not a professional programmer). > But it is not _always_ the "one true way". This would be more for > "unstructured" data. But, then, I need to be reading up on FTS so I could > well be wrong on this point too.
Heh, to be clear, I do not think you've put a foot in it, your advice was basically "look, you don't need a DB for that" and it is true and good advice for the specific case. Apart from the fact that SQLite ended up able to achieve the same speed as another option - many of Richard's and my subsequent points were based on the fact that you "might" need something more/something else in future, for which SQL will always win. This may well not be the case for the OP, but experience as a programmer (I'm more a programmer doing occasional reluctant DB admin) has taught that always always always, tomorrow will reveal a need that nobody saw today. When this happens, every time I had based system data on SQL, I smiled, and every time I did not, I cried. Hence the clear bias :)
