MySQL API'lerini PHP ile karıştırabilir miyim?


106

Ağı aradım ve şimdiye kadar gördüğüm şey şu mysql_ve mysqli_birlikte anlamını kullanabileceğiniz :

<?php
$con=mysqli_connect("localhost", "root" ,"" ,"mysql");

if( mysqli_connect_errno( $con ) ) {
    echo "failed to connect";
}else{
    echo "connected";
}
mysql_close($con);
echo "Done";
?>

veya

<?php
$con=mysql_connect("localhost", "root" ,"" ,"mysql");
if( mysqli_connect_errno( $con ) ) {
    echo "failed to connect";
}else{
    echo "connected";
}
mysqli_close($con);
echo "Done";
?>

Geçerli ancak bu kodu kullandığımda elde ettiğim şey:

Connected
Warning: mysql_close() expects parameter 1 to be resource, object given in D:\************.php on line 9
Done

Hariç ilk ve aynı şey için mysqli_close(). İkincisi için.

Sorun nedir? mysql_Ve mysqlibirlikte kullanamaz mıyım? Yoksa normal mi? Bağlantıların geçerli olup olmadığını kontrol etmenin bir yolu var mı? (the if(mysq...))


5
mysql kullanımdan kaldırıldı, sadece birlikte çalışmayacakları mantıklı. Neden bunu yapmaya çalışıyorsun ..?
Sterling Archer

7
mysql_*Fonksiyonları tamamen kullanmaktan kaçınmalısınız . Hataya eğilimli ve güvensizdirler ve yakında PHP'den kaldırılacaklar ( şu anda kullanımdan kaldırılmış olarak işaretlenmişlerdir ). [Bu harika yanıt] [0], neden kötü olduklarını açıklayan daha fazla ayrıntıya giriyor . [0]: stackoverflow.com/a/12860046/1055295
Andrei Bârsan

2
1) Eons'dan beri belgede kullanılmayan eski bir arayüz (mysql) kullanmakta ısrar ediyorsunuz 2) garip bir nedenle doğru şeyi yapmak ve yenisine dönüştürmek yerine onu halefiyle karıştırmak istiyorsunuz 3 ) İşe yaramadığına o kadar şaşırıyorsunuz ki, SO'da bu konuda soruyorsunuz, ancak yaptığınız şeyin saçma olduğu oldukça açık olmalı.
fvu

1
Bu bir batıl inanç değil. Elbette mysqli_*işlevlerle kötü kod yazabilir ve işlevlerle iyi kod yazabilirsiniz mysql_*. Ancak ikinci kategori, düşük işlevler kümesi olduğundan, OO tarzı çağrıları veya hatta hazırlanmış ifadeleri destekleyemediğinden (yalnızca iki örnek belirtmek gerekirse) kullanımdan kaldırıldı olarak işaretlenmiştir. Aynı işi yapmak için, biri uzun vadede açıkça daha iyi ve daha esnek olan iki araç seçeneği göz önüne alındığında, doğru cevap açık değil mi?
Andrei Barsan

1
Tabii ki değil. Bununla birlikte, kullanımdan kaldırılmış işlevsellik ile aktif olarak desteklenen işlev arasında seçim yapma seçeneği göz önüne alındığında, örneğin kendi soyutlamanızı yuvarlamak için, neden eski işlevleri kullanasınız?
Andrei Barsan

Yanıtlar:


66

Hayır, kullanamazsınız mysqlve mysqlibirlikte. Ayrı API'lerdir ve oluşturdukları kaynaklar birbirleriyle uyumlu değildir.

Yine de var mysqli_close.


Yine de bağlantıyı kapatmanız gerekmese de; nesneler artık hiçbir yerde referans alınmadığında kendilerini temizler. (Düz eski kaynaklar bunu, ama emin değil misiniz olmadığını nesneler aslında bir-önemsiz değil derecede de ray yararlanabilirsiniz.)
Chao

@cHao sadece bu değil, PHP, betik çıktığında tüm açık MySQL bağlantılarını kapatacak
Explosion Pills

1
Ama her zaman değil, benim tecrübelerime göre, bu yüzden her zaman dosyanın en altına bir kapanış koyuyoruz.
RationalRabbit

14

Burada üç MYSQL API'sinin tümü hakkında bir referansla birlikte genel bir cevap vermek gerekirse:

Üç (herhangi karştramazsnz mysql_*, mysqli_*, PDOsadece iş değil, birlikte PHP itibaren) MYSQL API. Manuel SSS'de bile var :

Öyle uzantıları karıştırmak mümkün değildir . Bu nedenle, örneğin, bir mysqli bağlantısını PDO_MySQL veya ext / mysql'ye geçirmek çalışmayacaktır .


Bağlantıdan sorgulamaya kadar aynı MySQL API ve ilgili işlevlerini kullanmanız gerekir.


Bir adam bugün bana mysql_real_escape_string()kodlarının geri kalanının PDO olduğu ile karıştırırken hiçbir problem / hata olmadığını söylemeye çalıştı . Bu farklı API'lerle çalışırken zamanımda burada elde edemediğim bir şey var mı? Burada cahil olan ben miyim? Bu, "şimdi silinmiş" soru içindir. Stackoverflow.com/q/34209127, yalnızca birinin merak etmesi durumunda 10K + üyeler tarafından görüntülenebilir. $stmt3->execute(array('classID' => $_POST['class'],'studentID' => mysql_real_escape_string($substr)))Bununla ilgili olarak - Burada bir şey mi eksik?
Funk Forty Niner

1
@ Fred-ii- Haklısınız :) El kitabını okumak doğru olduğunuzu gösterir . Ne muhtemelen oldu yani, mysql_real_escape_string()olacak sessizce denemek varsayılan parametrelerle bağlantı kurmak sonra OP için çalıştı. Böylece karakter setini almak için bağlantı kurdu. Yani OP'nin 2 bağlantısı var
Rizier123

OP en azından bana / bize muhtemelen 2 ayrı bağlantıları olduğunu söylemiş olsaydı, muhtemelen kabul ederdim; aksi karar verdiler. Ancak yine de nasıl çalışacağını göremiyorum. Varsa şaşkınım.
Funk Forty Niner

@ Fred-ii- Bakınız: link_identifier Birlikte aldığı varsayılan bağlantı ayarlarını kullanacaktır ini_get(). Yani muhtemelen varsayılan ayarlarla OP için çalışır. Onu bırakıp yeni bir kahve alırdım (☕☕☕).
Rizier123

Hakkında bir şeyler eklemek isteyebilirsiniz sqlsrv_query(). Burada bir soruyu
kapattım

2

Teknik olarak istediğiniz kadar ayrı bağlantı kullanabilirsiniz, ancak sorununuz yalnızca bir yazım hatasından kaynaklanır - yalnızca bir uzantıdaki kaynakları diğerinden işlevlerle birlikte kullanamazsınız, ki bu oldukça açıktır.

Ancak, tek API veya farklı API'lardan bağımsız olarak aynı komut dosyasından birden fazla bağlantıdan kaçınmalısınız . Veritabanı sunucunuzu yükleyeceği ve kaynaklarını tüketeceği için. Dolayısıyla, teknik olarak yapabilseniz de, kısa süreli yeniden düzenleme dışında kodunuzda farklı uzantıları karıştırmamalısınız.


Bu muhtemelen iyi bir fikir olsa da, bu nedenle bağlantı havuzu geliştirildi. Bir web sunucusuna gelen birden fazla web isteğiniz olduğunda, aynı bağlantıyı kolayca kullanamazsınız, bu nedenle yeni bir bağlantı açarsınız. Bağlantı havuzu, uygulama sunucusundaki ve veritabanındaki ek yükü kaydeder.
Doug

-3

MySQLiMySQLartık kullanımdan kaldırılmış olandan çok daha güvenlidir . Bu yüzden bağlı kalmalısınız MySQLive her ikisi de farklı olduğu için onları karıştıramazsınız.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.