Rate class to work with MySql

I wanted to answer and forgot. I do not pretend to a complete analysis, I just show the places that, in my opinion, should be shipped as soon as possible.

 <?php Class bd{ 

The first problem is formatting. Class always written in small letters, the name of the class - with a large, so-called. StudlyCaps , while the class name should clearly indicate what it does (not bd , but DatabaseApi , at least). Opening quotes taken to move to a new line. These are all trifles, but I see no reason not to do them right away. The relevant standards are PSR-1 , PSR-2 , they are now used by the entire professional community. To check your own code for compliance with formatting standards, you can use the PHP Code Sniffer utility ( github / packagist ).
Here at this stage:

 public function get($table,$columns='*',$filter=false){ 

The code is already becoming unreadable. You understand that saving gaps does not make sense?

Further - these are the constructions.

 $filter !== false 

Must be:

 !$filter 

It makes no sense to check for an exact match for false , if all other false values ​​are exactly the same cannot be used. Ternary operators are often simplified:

 $string = $probablyFalse ?: ' WHERE ...'; 

With this use, it will return either false , which, when concatenated, will turn into an empty string, or the necessary string. If desired, you can still put (string) before ternarkoy.

In this case, $filter will take either the value false , or ' WHERE ...' , and when concatenated, false will become an empty string.

 //преобразовываем их в двух мерный массив и возвращаем ^ ^ //если переданные данные не являются ,не строкой и не числом преобразовываем их в json-данные ^ ^^ ^ 

The rules of an ordinary human language, unfortunately, must be maintained even in the comments.

 gettype($val) !== 'string' || gettype($val) !== '"integer"' 

Another wrong design. First, integer in quotes, and secondly, what happens if you make a mistake on a character in a string with a type (in fact, this is what happened with quotes)? The program will not work correctly, and debugging will be quite painful. At the same time, PHP has ready-made functions for checking any type:

 !is_string($val) || !is_int($val) 

The next thing that strained:

 $sql_data = substr($sql_data, 0, -1);//обрезаем лишнюю запятую 

You should not cut off the extra comma, you should not generate it at all . In all languages, there is a glueing function for a string array, in PHP this is an implode($delimiter, $list) function that will glue this array to you.

Concerning such constructions:

 "INSERT INTO `$table` ($keys) VALUES ($values)" 

There is a function sprintf , with which it is customary to do such things. It will, of course, produce an absolutely identical effect, but this is a somewhat more readable approach:

 $query = sprintf('INSERT INTO `%s` (%s) VALUES (%s)', $table, $keys, $values); 

By variable name: write them completely, $value instead of $val , $config instead of $cfg . From the interpreter will not lose anything. But reading will be more pleasant.

The last formatting and general style is the forbidden trick:

 while(($row = $result->fetch_assoc()) != false) $results[] = $row; 

In an amicable way, it should look like this:

 while ($row = $result->fetch_assoc()) { // false-то зачем? $results[] = $row; } 

Write as if your potential reader raises the site for the twentieth hour or spilled half a bottle of whiskey (and so it will be sooner or later).

Now, by filling: you make a class for convenient work with the database, abstracting from it. But for some reason you are forced to transfer the condition and the selection of fields in a string. Why should I use such a class if I still write the half-line that I would have written in whole? In the opencard there is the same example, brought to the point of absurdity:

 // index.php?route=product/product&product_id=42&limit=2 $url = $this->url->link('product/product', 'product_id=42&limit=2'); 

Here is the condition:

 if(gettype($val) !== 'string' || gettype($val) !== '"integer"') $val = json_encode($val); 

Only by happy coincidence will it skip null , as it should, and at the same time will return false and true , and only the good will of MySQL would convert them to 0 and 1 respectively. "Would" - because the line below the code will perceive them and process them as a line (plus, again, you need a sprintf here, it is difficult to read):

 else $sql_data = '`'.$this->mysqli->real_escape_string($key).'`=\''.$this->mysqli->real_escape_string($val).'\', '; 

As a result, if false sent to the database, the string 'false' will return from there, which will never be perceived by PHP as false . This is data loss.

According to the names of the methods: there is a generally accepted unwritten convention of the name CRUD (create, read, update, delete), why call the methods differently?

The last one is this one:

 public function connect($cfg){//Функция подключения ,при вызове передаём настройки с данными от бд $this->mysqli = new mysqli($cfg['bd']['host'], $cfg['bd']['user'], $cfg['bd']['password'], $cfg['bd']['name']);//подключение к бд 

First, why is there an extra level of nesting with the 'bd' key at all? Secondly, why not prevent errors at an early level and force the user to pass the required parameters?

 public function connect($host, $name, $user, $password = null) 

And, of course, they have already said about injections and placeholders.