PDO vai tomēr MYSQLI

[Valcha]

Jautājums pieredzējušajiem. Beidzot esmu nolēmis atteikties no manuālā mysql_real_escape_string un pāriet uz PREPARED STATEMENTS. Neredzu nepieciešamību tuvajos gados pāriet uz citu DB.

 

Salasījos 3 gadus vecos rakstos, ka PDO ir lēnāks par MYSQLI. Kāda ir jūsu pieredze mūsdienās? Lasu rakstus, apskatus, katrā ir pilnīgi cita versija par ātrdarbību. PDO galvenā būtība jau ir viegla pāreja uz citām DB, bet tas man nav aktuāli...

 

Varbūt vēl kādi ierosinājumi sakarā ar šo izvēli / pāreju?

 

Cik jau paspēju saskarties, MYSQLI problēma ir tas, ka PREPARED STATEMENTS selecta gadījumā nesaņem asociatīvu masīvu, tātad jāņem talkā pašrakstīta funkcija. Atkal - ātrdarbības samazināšana.

Edited June 3, 2010 by Valcha

[Trac3 !!]

Cik jau paspēju saskarties, MYSQLI problēma ir tas, ka PREPARED STATEMENTS selecta gadījumā nesaņem asociatīvu masīvu, tātad jāņem talkā pašrakstīta funkcija. Atkal - ātrdarbības samazināšana.

 

Asociatīvu masīvu gan var dabūt.. PDO neesmu lietojis, bet MySQLi gan iesaku ļoti ērti strādāt.

Edited June 3, 2010 by Trac3 !!

[Valcha]

Asociatīvu masīvu gan var dabūt.. PDO neesmu lietojis, bet MySQLi gan iesaku ļoti ērti strādāt.

 

Varbūt vari parādīt, kā ar MySQLi iegūsti asociatīvu masīvu? :) Tad es varbūt pagaidām nosliektos uz MySQLi.

[briedis]

Šitais vai ta nav?

 

http://www.php.net/manual/en/mysqli-result.fetch-assoc.php

[Valcha]

Šitais vai ta nav?

 

http://www.php.net/manual/en/mysqli-result.fetch-assoc.php

 

Nu it kā nav gan - kā tu izmanto prepare metodi, tā tālāk ir jāizmanto MySQLi_STMT execute:

$stmt = $mysqli->prepare("SELECT * FROM test WHERE id = ?"); 
$stmt->bind_param("i", $i); 
$stmt->execute(); 

 

Un pēc execute jau darbojas MySQLi_STMT metodes, kas, neatbalsta fetch_assoc.

[codez]

Es izmanotju extendotu mysqli klasi, kurai ir dažas funkcijas, kas automātiski escape-o datus un protams Singletona patterns instances iegūšanai, rezultātā kverijus rakstu šādi:

 

db::i()->q('SELECT * FROM users WHERE username=%s AND password=%s',$username,$password);

 

kverijs tiek apstrādāt ar sprintf, kuram par paremetru tiek nodoti tālākie parametri.

 

 

Vēl varētu uztaisīt vienkāršu query klasi un implementēt kā ArrayAccess.

 

$q=new query('SELECT * FROM users WHERE username={username} and password={password}');
$q['username']=$username;
$q['pasowrd']=$password;
//vai
$q->setData(array("username"=>$username, "password"=>password));

$q->execute();

Tālāk var šo klasi papildināt ar dažādām execute funkcijām, kuras atgriež vai nu mysqli_result, vai 1.row-a 1.vērtību, vai 1. rowu, vai 2d masīvu ar visu rowu visiem datiem.

 

 

3. variants ir izmantot kādu gatavu vai pašizveidotu ORM.

ORM ideja ir tāda, ka tajā kveriji vispār netiek rakstīti, bet tiek izveidots modelis, kurš nodrošina mapping-u starp PHP objektu un RDBMS datubāzi.

 

Tad katrai tabulai pretī ir viena klase, piemēram:

 

$user = new User();
$user->loadById('5');  //SELECT ....
echo $user->username;
$user->points++;
$user->save();  //UPDATE ...

 

Parasti pilnvērtīgā ORM visi kveriji tiek uzģēnerēti no tavām darbībām ar objektu.

ORM ir viens trūkums, var gadīties iebraukt neoptimāli saģenerētos kverijos, nav īsi iespējams uztaisīt ORM, kurš ģenerētu kverijus 100% visu SQL iespēju.

Edited June 3, 2010 by codez

[rATRIJS]

Var jau izmantot kaut kaadu pashveidotu metodi kaa jau codez saka, piemeeram:

 

public static function prepare($sql) {
   	$variable_count = func_num_args() - 1;
   	$variables = func_get_args();
   	$escaped_variables = array();

   	for($i=1; $i<=$variable_count; $i++) {
   		$escaped_variables[] = mysql_real_escape_string($variables[$i]);
   	}

   	$sql = vsprintf($sql, $escaped_variables);

   	return $sql;
}

[mefisto]

PDO

[Valcha]

Es izmanotju extendotu mysqli klasi, kurai ir dažas funkcijas, kas automātiski escape-o datus un protams Singletona patterns instances iegūšanai, rezultātā kverijus rakstu šādi:

...

Codez - kam par godu izvēlējies tieši mysqli nevis PDO? Vai tādēļ, ka plānoji izmantot tikai mysql, vai bija kādi citi iemesli?

Šobrīd notiek tieši tā nosliekšanās uz vienu vai otru pusi. Pagaidām kaut kā patiešām vairāk velk uz MYSQLi.

[codez]

1)Jā, ārpus MySQL netaisījos līst un joprojām nav bijusi vajadzība pēc citām sql db.

2)Nepatika PDO pieraksts - likās tāds smagnējs un neērts.

[Valcha]

Tagad te papētīju...

Mīnusi:

1) Nav asociatīvo masīvu. Pašam jāpārlisto masīvs

2) Order kolonnas, kas nāk kā mainīgie, tāpat jāapstrādā ar mysql_fetch_array(). Tāpat arī citi mainīgie, kas var apzīmēt kolonnas vaicājumā.

3) Vispirms visam ir jābūt iefetčotam un tikai tad var veikt nākamo selektu.

 

Laikam es īsti nesaskatu PREPARED STATEMENTS ieguvumus...