On Sun, 31 Jan 2016 17:22:37 +0000 Simon Slavin <slavins at bigfraud.org> wrote:
> > Ignore all the above. There are rare situations where they're useful but the > situation you're in is helped far more by using the phonebook analogy earlier > posters used than by trying to use the above. > > Think about pure SQL, and about making one ideal index for each SELECT > command, and you'll get very good results. Work out what you want the SELECT > (or UPDATE, etc.) to do. Then work out the command. Then work out the index > which would be ideal to help the command do its thing. That's the best way > to get fast SQL. > > Optimizing for SQLite peculiarities (some of which no longer apply because > inner workings of SQLite have changed since the article was written) is > useful only very rarely. > I agree. I'm, drifting to much far from one of my concern to stick to just SQL (and standard SQL). In the meantime, I was looking at what SQLite do with the queries, to see if it's intuitive, if it matches enough what one would devise without a DB engine. I mean I sometime think about SQL as a data structure modelling language, and I may try to re?implement in a classic procedural language, for an experiment. I'm also aware this point of view (SQL as a data structure modelling language) is less meaningful with complex queries, as with these, a DB engine adds values outweighing the hopes one may get from a procedural implementation, ? the same if the set of queries is not fixed. That said, thanks for the recall. -- Yannick Duch?ne
