Good practice in PHP would be to use $_REQUEST rather than $_GET; that way your script will work with both GET and POST. I'd also strongly suggest that you rewrite that code to use a prepared query, which will be much, much safer - depending on the values of the variables, your SQL could end up hopelessly mangled, and potentially vulnerable to an injection attack.
Try something along the lines of
$query = $conn->stmt_init() ;
if ( $query->prepare("INSERT INTO mytable SET NV = 1, name = ?, orig = ?, state = ?, opi = ?") {
$query->bind_param('iiii',$_REQUEST['name'],$_REQUEST['orig'],$_REQUEST['state'],$_REQUEST['opi']) ;
$query->execute() ;
}
Note that in bind_param, I've assumed each column is an integer (iiii); if not, replace the i with s for string, eg if name is a string and the others are integers, use 'siii'.
If you don't want to use a prepared statement, then you must at the very least sanity check that data, and use real_escape_string. For example (and assuming name is a string, others are int)
$sql = sprintf("INSERT INTO mytable SET NV = 1, name = '%s', orig = %d, state = %d, opi = %d",$conn->real_escape_string($_REQUEST['name']),$_REQUEST['orig'],$_REQUEST['state'],$_REQUEST['opi']) ;
$conn->query($sql) ;
Building the query with sprintf like this has two advantages - one is that it's much easier to read, and to spot quoting mistakes. And secondly by using %d you force an integer value for fields that are int, even if the parameters passed are strings.
It's also a really good idea to do sanity checking, for example, if state might be one of three options ( 'ready', 'waiting', 'done'), and opi should be an int you might say something like:
$state = (( $_REQUEST['state'] == 'waiting' ) || ( $_REQUEST['state'] == 'ready']) || ( $_REQUEST['statue'] == 'done')) ? $_REQUEST['state'] : 'waiting' ;
$opi = ( intval($_REQUEST['opi']) == $_REQUEST['opi'] ) ? $_REQUEST['opi'] : 0 ;
to force the value to be 'waiting' if it's not one of the valid options.
This may seem like overkill, if you think only your app will ever talk to that server, but believe me - there are plenty of people who will throw anything they can at a script that they suspect might give access to an SQL database.