On 9 Nov 2014, at 1:49pm, Tristan Van Berkom <tris...@upstairslabs.com> wrote:
> This year in particular I've been faced with my first queries of modest > complexity, see for example this (temporary) paste: > > http://www.fpaste.org/148918/41545194/ > > This is the beginnings of a query which will try to fetch an available > employee for a given 'task', ordered eventually by their relevance, > first set 'is it their job ?' second set 'do they have the licenses and > formations to actually perform the task, even if it's not their job' ? > and so on and so forth. > > I've found that when trying to bend my brain around these problems of > modest complexity, they are only understandable if I visualize them in > terms of 'sets of rows' and how they join to each other. I haven't looked into your specific example in depth, but you should also be aware of another solution to this problem: Make a good but simple SQL query that gets you some way to your data, then parse the resulting rows using your programming language. This can lead to a far simpler program which is faster to write, easier to debug, and more flexible than what can be done entirely inside SQL. Just because one can write complicated iterating queries with sub-SELECTs in SQL doesn't means one should. There comes a point where it's batter to do the work inside whatever programming language you're using. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
