[TriLUG] SQL-fu help request
Igor Partola via TriLUG
trilug at trilug.org
Tue Feb 24 11:35:21 EST 2015
Any time! I would do a few tutorials regarding MySQL/SQL in general to get
the lowdown on JOINs, ORDER BY, GROUP BY, LIMIT, and subqueries. Or just
read the relevant chapters in the MySQL animal book.
Glad to hear you are using PDO/MySQLi and prepared statements. I would do
that everywhere just to make a habit of it. For input validation, yes if
you are dealing with ints, like page size and number, you can probably get
away with it. I personally would write that as:
$sql = sprintf("SELECT ... LIMIT %d, %d", $offset, $page_size);
That way int casting is explicit. To be perfectly honest, there are times
when composing a string query is a good idea: performance is better this
way. However, it really is very error prone. Today, you have your int
casting, tomorrow an intern adds a feature and accidentally removes it, or
overrides the variable name, etc. It happens, and then it's only a matter
of time before an automated scanner picks it up. If you did your int
casting properly, then your query is not immediately dangerous, but it can
become dangerous with changes to the code above it. Better safe than sorry,
especially since using prepared statements will likely result in less code.
Re: PHP. It is an easy language to learn coming from C because of its
syntax and because it requires very little setup to get to Hello World.
However, it is a terrible language. Take a look at http://www.phpwtf.org/.
Things like being able to implicitly cast arrays to strings and back to
arrays is bad, for example. So if you at some point did C, using Python and
Django should be no challenge, and it is in all respects better and safer.
Igor
P.S.: Thanks Alan and Randy! If I was in RTP, I'd gladly give a talk about
MySQL. Sadly, I don't think even with today's video conferencing
technology, doing a talk remotely would work out that well.
More information about the TriLUG
mailing list