My impression is that stored procedures are much less commonly used
than sending plain strings across the wire to the DB. I don't have any
data for this though, just my impression.
The common way to avoid SQL injections is to use some symbol to
represent a variable to be replaced on the server with something sent
out-of-band from the query; in the following, the sql query and the id
"555" are sent separately:
exec("select * from users where users.id = ?", 555)
There are cases where a stored procedure wont work, and apparently
they can become quite painful at times (I've heard bad stories about
using them from devs who have worked with them).
Regardless, the plain way of sending strings across the wire is very common.
On Wed, Aug 5, 2015 at 9:20 AM, Greg Hendershott
<greghendersh...@gmail.com> wrote:
> I agree SQL is an interesting analogy but I draw the opposite
> conclusion, if I correctly remember what I did ~5 years ago.
>
> There is an eval-ish way of using SQL, such as forming SQL code out of
> strings. This tends to perform slower and is extremely vulnerable to
> injection and other unexpected behavior.
>
> However you can also make stored procedures with explicit arguments.
> Not only is this safer, it usually performs better because the query
> execution plan can be precompiled (IIRC).
>
>
> As for 3, using a domain specific language can be helpful. Especially
> a "declarative" one: "Here's the data I want, you figure out exactly
> how to get it." (Even though real-world performant SQL maybe isn't
> 100% "declarative", that approach still works better than any ad hoc
> database engine I'd create :), and it's a useful division of labor.)
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
