in reply to Re (tilly) 4: How NOT to do it
in thread How NOT to do it

Since no one has answered your challenge in 2 years, I'll ask:
Why is it very important that SQL not be a Turing complete language?
The only answer^W guess I can come up with is the rhetorical - imagine someone trying to code an OS or any complete program in a database. But I don't really know. Thanks.

Perl programming and scheduling in the corporate world, as explained by dragonchild:
"Uhh ... that'll take me three weeks, broken down as follows: 1 day for coding, the rest for meetings to explain why I only need 1 day for coding."

Replies are listed 'Best First'.
Re: Re: Re (tilly) 4: How NOT to do it
by tilly (Archbishop) on Sep 17, 2003 at 04:38 UTC
    Sorry for being slow getting back, I have been offline.

    The answer is that the database is supposed to figure out exactly what the SQL is supposed to do, and then come up with a very efficient way to do that. With a Turing-complete language it is impossible to answer detailed questions about arbitrary code, and is difficult to answer them even for normal code.

    Sure, optimizers can speed up code. But in a normal language they can't recognize a bad algorithm and rewrite it with a more efficient one. But SQL routinely is optimized to be using algorithms which are far better than any that the developer would have thought up.

    SQL could not do this if the developer had, for instance, the freedom to write a series of nested loops with possibly relevant side-effects and a difficult to discern purpose.

[reply]
Re: Re: Re (tilly) 4: How NOT to do it
by antirice (Priest) on Sep 11, 2003 at 05:39 UTC

    It's that queries cannot be recursive. Of course, there have been a number of papers popping up here and there about Turing-complete SQL extensions.

    antirice    
    The first rule of Perl club is - use Perl
    The     ith rule of Perl club is - follow rule i - 1 for i > 1

[reply]
      It's that queries cannot be recursive. Of course, there have been a number of papers popping up here and there about Turing-complete SQL extensions.
      I can see how recursive queries could get rediculous, but why prevent that ability? Is it dangerous? Does it violate DB 'best practices'?

      I don't know much of anything about DB internals, or even the interfaces, so I'm groping here.

      *sigh* I just used a PHBism. Where's that lobotamy brochure?

      Perl programming and scheduling in the corporate world, as explained by dragonchild:
      "Uhh ... that'll take me three weeks, broken down as follows: 1 day for coding, the rest for meetings to explain why I only need 1 day for coding."
[reply]

        The reason is pretty simple: a database is a place to store and retrieve data. Creation of data is not up to the database. The database stores data and you ask it to present a relational view of the data stored based upon certain parameters. Regardless of how you relate the tables in your sql statement, you will get a finite amount of data back. Just for a wonderful nightmare, imagine a select statement that recursively inserted into the same table that it was selecting from. Of course, the fact that the database will return a finite amount of data is somewhat nice in my opinion.

        Hope this helps. If I made no sense, it's because I've been up for more than 24 hours :-/

        antirice    
        The first rule of Perl club is - use Perl
        The         ith rule of Perl club is - follow rule i - 1 for i > 1

[reply]

In Section Meditations