I was seeing a script in php and I noticed that every time an SQL query was written, this "operator" was used.
A part of the code
$sql = "INSERT INTO categorias (nome) VALUES(:nome)";
$stmt = DB::prepare($sql);
$stmt->bindParam("nome", $data->nome);
So what's the point of using this "operator"?
This syntax is used by PDO to append parameters to prepared statements through function bindParam() .
It is very useful for implementing security when using information coming from forms, or even for the dynamicity of a query.
Example:
<?php
/* Execute a prepared statement by binding PHP variables */
$calories = 150;
$colour = 'red';
$sth = $dbh->prepare('SELECT name, colour, calories
FROM fruit
WHERE calories < :calories AND colour = :colour');
$sth->bindParam(':calories', $calories, PDO::PARAM_INT);
$sth->bindParam(':colour', $colour, PDO::PARAM_STR, 12);
$sth->execute();
?>
Source: link
Friend, you did not show all your code but I think this =: is not an "operator."
The correct interpretation would be = and : id , where : id is related to the id name parameter > that must be passed at the time of execution.
More information here .
Although they represent the same thing, parameters and placeholders differ in the way they are presented in a statement .
Parameters are nameable, allowing them to be easily identified across all the terms of the SQL pseudo-language. Because it is a simple string, it requires something that allows them to be identified during the DBMS interpretation. This form of identification is usually the colon character.
Placeholders , however, are not nameable. They just reserve a place for real values. These are usually used in the middle of the statement .
Parameters, or named placeholders , has the advantage of interacting with dynamic arguments once a key / value association is made, ie the parameters found in the statement in> are searched in the list of linked parameters and a simple replacement is done.
Placeholders , however, are numerically indexed and are arranged in the statement by their positions and therefore require a little more attention, otherwise you may end up accidentally linking ( binding ) an integer to a column in the database that represents a float and, at best, receive an incorrect result.
Before you know why the colon is being used in a query, you have to understand what prepared statements are and how they differ from a direct execution.
Let's look at the typical workflow when using an prepared statement :
A statement template is created by the Application and sent to the DBMS. Of the values assigned in the query, some can be omitted. These are called the parameters, , or bind variables .
INSERT INTO PRODUCT (name, price) VALUES (:name, :price)
Or
INSERT INTO PRODUCT (name, price) VALUES (?, ?)
The DBMS analyzes, compiles, and executes a series of optimizations in the declaration model and stores the result without executing it .
Later, the Application provides (or binds ) values to the parameters and the DBMS executes the declaration possibly returning some result. The Application can execute the same statement as many times as it needs, with as many different arguments as it can or needs to provide.
If we compare with the direct execution of statements, prepared statements have two main advantages:
The cost in terms of processing to compile and optimize the declaration is incurred only once, even if it is executed multiple times. However, it is worth noting that not all optimization techniques have the best optimization depending on the type of argument received, as the best strategy today may not serve in the future, near or not, given the possible changes in structure and index of a table.
There are those who say that prepared statements are not as advantageous for once-performed queries given all the extra procedures and that this may be a performance penalty for the Application. I disagree as this depends on N factors, from hardware scalability to how well the application was programmed.