I'm developing a basic php based function that executes MySQL queries in order to sort the data in the database and present it to the user. As a general statement, is it considered best practice to simply construct static queries and to execute them as needed, or simply piece together elements of a MySQL statement based on conditions?
To narrow the question, I have a specific example:
Say I have a few drop-down menus that define the search on the user's end. Let one drop-down simply contain a list of names, say Bob Smith, and the two others a date range. From there, I can easily create a search along the lines of SELECT item FROM checkOUT WHERE... I can definitely write a general query with parameters to be executed when ALL three of the parameters are present. Consider the case when only a date range is selected regardless of individuals - that would require only two parameters and a different general query. And what if the data is spread across multiple tables? That has to be taken into account. I should add as well that my function is based on drop-down menus - not original user input.
Basically, what would be the best method to create the MySQL Query - prepared statements or dynamically created statements? Obviously, the end result will rely on a hybrid of the two, but to which side it leans the farthest is the issue. I'm asking this question as I am not too familiar with this particular side of handling multiple queries from one source. Typically, I simply have to execute one query to get what I need and work with it - not sorting.
Any insight is appreciated.
I usually make a $where variable and an $order variable and then build them based on the filter input from the page. Then i just append that to the base $sql variable and run it. Seems to work great for me. Just don't forget to escape any nasty input from the user before running the query though.
Related
This question already has answers here:
How can I prevent SQL injection in PHP?
(27 answers)
Closed 3 years ago.
I asked this question earlier Preventing SQL Injection in dynamical SQL, but was not clear which resulted in the question being closed, and was later told in the comments that I should ask the question again.
A requirement of my PHP/MySQL application is to allow all users to create their own multiple "views" of the data. These views are not traditional SQL views, but performed by the application.
For instance, the user could create a view and provide the following criteria:
Name of the view.
Desired records per page.
Which columns to display by using a dropdown menu.
Any filters for the results. A first dropdown menu is used to select the column, a second dropdown menu is used to select the operator (equals, not equal, greater than, etc), and then either a third dropdown menu is used to select the value to be matched or the user directly enters the value to be matched.
Whether the records should be grouped on a given column.
Based on the user's selection, various tables might need to be joined to the query to support the select, where, and group by clauses, and the application is used to eliminate duplicate table joins should they exist.
After the user has finished configuring their views, there is a dropdown menu which allows them to select their desired view, and the appropriate results are displayed.
I have implemented this functionality by storing the user's selections in several tables, and also storing the resultant query (actually, I store individual sections of the query in various columns so I may count the total results in an initial query and return the correct number of results in a second query) in a SQL table. Note that I am storing the user's selections only so that I can allow them to edit their view requirements, and not to create the resultant query on the fly (more on this later).
I recognize that I have to be very careful as doing this can be prone to SQL injunction. For instance, I can't just escape the user's input using PDO and store it in the database, and then later retrieve the data and use it in a query since when it is retrieved, it is no longer escaped.
To combat this risk, I limit user input to integers wherever possible, and typecast them where possible. Where user inputs are percents and dollars, I multiply by 100, typecast the resultant as an integer, and then divide by 100 before storing it. A couple of the filters require text as the value in the WHERE clause, and as stated earlier, escaping the data is not enought, and instead I am using $user_input= preg_replace('/[^a-z0-9,]/i', '', $_POST['user_input']); to make safe.
Is this an accepted method to implement this functionality? Is there an easier way to ensure the user input is safe? My earlier post Preventing SQL Injection in dynamical SQL indicated that this type of practice should never be attempted, however, I don't know how else to do it. Are there any other steps I should take to prevent injection?
Or maybe I should not create a query and store it in a table when the user saves his view configuration, but create the query on the fly using the user's saved values each time the user selects a given view. This would have a negative performance impact and add complicity but I suppose I can do it. Would you recommend using this strategy?
Thank you
Hello I get you I think.
This is what you are looking for:
http://www.php.net/manual/en/function.addslashes.php
$safestring=mysql_real_escape_string($_POST['user_input']);
$safestring=addslashes($safestring);
If you want to make it even more safer, that is the user cannot input html in the input,
use this function after using the above one (i.e. mysql_real_escape_string)
$safestring=htmlspecialchars($safestring);
Now all your use input will stay as it is,
if string is "user's input" it will stay as "user's input" and not change to "users input", so nothing is being replaced, and its still safe.
Regards.
I'm using PHP with the PDO library to work with a MySQL database, and I am fetching several thousand rows from a database based on two of the fields. Specifically, I need rows corresponding to certain latitude-longitude pairs, if such points exist. Currently, I am making a prepared statement and executing it once per point/row. What is the fastest way to fetch many rows like this? Just use a bunch of OR's?
It's impossible to answer to such a broad question.
The most general answer would be like this:
If you have to do this regularly - say, on a live site on each user's click - then, you have to reduce the number of parameters queried.
If it's just occasional operation - just leave it as is.
In other words, you don't need "fastest". You need "fast". Or even "reliable".
So, the context is: I have a site in which many pages may need the information about one table, say for instance, 'films'. This table has many fields, like title, language, year, description, director... And perhaps in one page I need only the title and the id of some rows and in another I also need the description.
So the question is: should I code a database manager (I am using MySQL) that retrieves all the fields of the rows that satisfy a condition (I guess the WHERE clause should be passed as a parameter)? Or should I be able to specify which fields are needed? I thinks this cannot be done easily with mysqli (because prepared statements require to specify beforehand the number of fetched fields), so for this to work I would need to use PDO instead, which I haven't used yet. Is it worth it this last approach? Or there is not really a big difference in performance if I retrieve the whole information about those rows?
Thank you in advance.
Based upon the comments above, My answer to your question(s) is
Retrieving some fields vs all fields isn't a real performance consideration until you are dealing with one or more CLOB/TEXT columns which have a lot of text in them. Good database practice indicates you should always specify which fields are returned from a query.
Any query against any table should have a where clause to restrict the number of rows returned. Especially if you are looking to query exactly one row.
Your question implies you are writing a wrapper layer around the queries to hide this complexity. Don't do this. Get an existing PHP library that does this work for you. See for example: Good PHP ORM Library? . There are a number of subtle issues, like security, which you will overlook.
I've searched this relentlessly and I cannot find an answer to my quandary - I think the problem is that I'm not exactly sure WHAT to search for! Anyhow, my problem is this...
Scenario:
Imagine having a database of, for arguments sake, recipes and you wanted to give users the ability to generate a list of recipe suggestions based on various criteria.
In the form of a web page, I would want this to be a series of drop down boxes on the left. The user would select their filter options from the drop down boxes and, after pressing the submit button, would be presented with a list of recipes that fit the criteria.
So they could, for example select 'Meal Type', 'Calories', 'Cooking Time' and then (after hitting submit) get back a list of recipe suggestions that fit the bill.
(Ideally they would appear without the need for reloading the page and would be contained within a slider to browse through, but I can probably crack that part if I get the underlying part sorted...)
Requirement:
I just need to know - at a top level - which technologies I would use to achieve this (and the process of how they work together).
I'm guessing I'd need a MySQL dB with recipes that are tagged with criteria, then use the form and php to pull from the database. Is this correct?!
Seems like such a common requirement, but I can find no good reading on how to achieve this..
Take a look at the PHP guide to prepared statements. You'll be basically writing a select statement against the table where your data resides, with the where clause of the select statement being the parameters selected by your user in the form.
PHP Prepared Statements
The reason you want to stick to prepared statements is that they are generally more secure against attacks on your site via the form, using SQL injection.
For the end to end solution, your front end will submit to a PHP page which will then handle the criteria specified by the user, translating those into the prepared statement which will find the data from your table. The table itself will need to have columns which correspond to the criteria. That gets more into database design which is a much larger topic to cover here, however there are plenty of guides out there for that.
Really you want to break the solution down into the subcomponents, then find various guides out there to tackle the parts. Good luck, hope this helps. :)
The process:
1) User makes selection and clicks submit button. That will initiate a HTTP POST to a PHP page (can be the same PHP page) where you would collect these information.
2) Open a MySql database connection with PHP. You would need to know SQL to pull data from MySql DB. Depending on how your database schema is laid out.
3) Once you pull this information display them as a checkbox where user can click.
This is the bare minimum.
If you wanna get a bit more fancy you can use JQuery ajax post (http://api.jquery.com/jQuery.post/) so the page does not refresh.
Good luck and I'm already hungry. haha.
When the user selects options in your form and submits it, this will run a PHP script on the server. The server retrieves the option parameters, and uses them to construct a SQL query. For instance, the script might contain something like:
$criteria = array();
if (isset($_POST['calories'])) {
$criteria[] = 'calories < '.$_POST['calories']);
}
if (isset($_POST['time'])) {
$criteria[] = 'cooking_time < '.$_POST['time']);
}
...
$query = 'SELECT * FROM recipes WHERE '.implode(' AND ', $criteria);
You use a library like mysqli or PDO to perform the query and get the results. Then you loop through the results, and format them into an HTML table which will be returned to the user as the resulting web page.
Or the PHP script could return the results as JSON data. Your web page could use AJAX to get this data from the server, then use JavaScript to format it into a table.
I have a situation for which I want best solution as I already know a way to complete that. Only problem is I am facing the similar requirement times and again.
Situation is, I have multiple select lists in a single form and every select list has couple of items, client wants translation for those items.
So if I create a table for every select list then if I have 10 select lists then I have to fire 10 queries, which I want to know is OK because I don't see it fine.
Or I can create language file where I can declare those array and include that file as per selected language.
Can anyone share their experience tackling with this particular solution, how can we solve this problem in the best possible way.
Thanks in advance.
Unless every ounce of performance is a concern to you right now, I don't think there's anything terribly wrong with having 10 separate queries (provided they reuse the same database connection).
If that leaves you uncomfortable, you could retrieve all of the select box options for a given language with a single query (either by using UNION, or normalising your data so that a single table contains all of your select box options and columns indicate to which list and language each record belongs); then PHP could split apart the results of that single query accordingly.
But, as your question specifically asked about best practice, you might like to read up on PHP's support for gettext() (as described in this question) or look into a framework that provides localisation features.