On 12 Jun 2009, at 11:14pm, Allen Fowler wrote: >> You'll probably find it easier to write the processing algorithm in >> the >> programming language of your choice. This will allow you to print >> out >> diagnostics as you go along, play with a debugger etc. To make it >> easy >> to map back to SQL you should structure it as a for loop over the >> rows >> of data with inclusion/exclusion conditions at the top of the >> loop. If >> you decide to express it in SQL again you can then run your correct >> language code against SQL and compare the results as your test >> framework. (Strictly speaking you are already doing this but the >> programming language is your brain :-) >> > > > Thank you for the advice.... Can you point me to some examples of > code in a traditional language and the equivalent in SQL?
I'm not sure you appreciate what Roger (please be more careful about your quoting, by the way) is telling you. SQL is not a programming language. It's a way of accessing a database. The two are not at all equivalent: everything you can do in SQL you can do in any good programming language, but not vice versa. You're being urged to write your program, not to try to use as many SQL tricks as you can. Write code to manipulate dates and times, to implement repeating events, and to present a decent user-interface to your users. SQL is going to do lots of work for you but it's not going to come up with all the answers you want. Sooner or later you're going to have to do some filtering or sorting in your software. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
