| Re: str_replace does not like empty quotes [message #186283 is a reply to message #186282] |
Mon, 23 June 2014 00:44   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 6/22/2014 7:20 PM, Geoff Muldoon wrote:
> jstucklex(at)attglobal(dot)net says...
>
>>> Of course, bind variables are massively better, but I doubt that
> Richard
>>> is up to knowing about them yet.
>
>> One opinion. But bound values have their problems, also. They are
>> neither better nor worse than properly escaping values. Just another
>> way of doing things.
>
> Hmm, I've never really found any signifcant down-side to using bind
> variables if they are used corrctly, so I'd appreciate any links you
> might have.
>
> IMHO three of the main pluses are:
>
> a) A strong (but not totally foolproof) barrier against SQL injection
> attacks.
>
> b) On certain platforms (perhaps on Oracle more so than MySQL, etc.) the
> ability to shared pool cache or soft-parse rather than hard-parse a
> particular execution plan, often significantly increasing performance
> when querying the same columns from the sames tables.
>
> c) Parameter input values do not NEED to be properly escaped.
>
> http://en.wikipedia.org/wiki/Prepared_statement
>
> GM
>
Performance, for one. Bound values require at least one extra call to
the libraries (for the PREPARE).
Additional calls are required to bind numeric values. Of course they
are also required for string variables, but since strings need to
otherwise be processed through mysql_real_escape_string(), that's a push.
Additionally, values should always be validated before being used in a
mysql request anyway.
The extra processing can be excessive in a busy site. Of course, if
you're only getting 100 hits/day, it's not a problem.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]