On Thu, Mar 8, 2012 at 4:37 PM, Simon Slavin <slav...@bigfraud.org> wrote: > That's why you don't make a DBMS (SQL) do the job of a programming language. > Use your programming language to to retrieve the values you need to make your calculations. Then use your programming language to figure out the new values and execute the UPDATE commands needed to make the changes.
Lots of people want to and do use SQL to do a lot of what a regular programming language can do. Some are even taking SQL and applying it to new problems. See ql.io for example. One very nice thing about using SQL to do more is that you can do a lot of prototyping from a SQL shell and then start on the scaffolding around it in whatever other language, and if you do it this way you'll probably find yourself doing a lot of programming in SQL. > SQL is not a programming language. Trying to use it like one leads to > ridiculous contortions which take longer to run than doing it all in SQL > would take. There's nothing magically fast about SQL, it still has to do the > same amount of work in the end. SQL was not, originally, a Turing complete language (unless one were to consider cross self joins of large tables for driving iteration as good enough), but nowadays it pretty much is, therefore it is a programming language. The language supported by SQLite3 is Turing complete, FYI, since you have conditionals (WHERE, WHEN, CASE, ...) and iteration (e.g., via recursive triggers). And the SQLite3 VM most assuredly is Turing complete. But, really, it's quite a hole that I can INSERT INTO table SELECT <complex query> but I can't UPDATE table <complex expressions>. INSERT OR REPLACE is almost a very good alternative. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
