Przełącz się na mysqli lub zostań z mysql?

Mamy tutaj aplikację, która była rozwijana (i obecnie w produkcji) przez ponad rok. Które łącznie ma ponad 500 mysql_* połączeń.Przełącz się na mysqli lub zostań z mysql?

Czy warto przełączyć wszystkie z mysql_* w kodzie do mysqli_*

Czy warto gonić wszystkie błędy, które mogą (i najprawdopodobniej będzie) doszło?

Widzę z pytań takich jak to: Changing this from MySQL to MySQLi?, które po dodaniu i po każdym wywołaniu mogą doprowadzić mnie do wielu błędów. Czy to jest warte mojego czasu?

mysql_* będzie prawdopodobnie na dłuższą metę (nawet wśród pogłosek o deprecjonacji), więc naprawdę warto każdemu programistom czas na metodyczne przejście?

See also this discussion

Źródło

2011-08-26 Neal

Zespół PHP wkrótce wycofa funkcje 'mysql_ *' w przyszłych wersjach PHP. Przeczytaj: http://news.php.net/php.internals/53799 – Buddy

@Buddy, jeśli przez "o" masz na myśli "może, być może, za kilka lat, myśli o rozpoczęciu rozważania". Edukacja poprzez dokumentację to wszystko, co wydarzy się w perspektywie krótko- i średnioterminowej. – salathe

@salathe, jeśli przez "krótki/średni czas" masz na myśli 1-2 lata, nie powinieneś używać 'musql_ *' w nowych projektach. Z tym rozszerzeniem w PHP wszystko będzie się działo. – Buddy

Cytowanie manual for ext/mysqli:

Rozszerzenie mysqli posiada szereg zalet, najważniejsze ulepszenia ponad istoty rozszerzenia mysql:

obiektowe interfejs

Wsparcie sporządzanych sprawozdań

Obsługa wielu instrukcji

Obsługa transakcji

Rozszerzone możliwości debugowania

wbudowanego wsparcia serwer

Uwaga: Jeśli używasz wersji MySQL 4.1.3 lub nowszego zaleca się stosowanie tego rozszerzenia.

Jeśli potrzebujesz tylko jednej z tych funkcji i możesz sobie pozwolić na refaktoryzację, to tak, idź do tego. Jeśli nie potrzebujesz żadnej z tych funkcji, nie rób tego. Nie ma powodu do refaktoryzacji, jeśli nie ma żadnych korzyści.

On a sidenote, the rumors are true. ext/mysql will likely be deprecated (chociaż nikt nie może powiedzieć, kiedy w czasie pisania tego tekstu na pewno nie będzie przestarzałe w wersji 5.4 i prawdopodobnie będzie dostępne jako przedłużenie pecl na zawsze) W żadnym wypadku nie powinieneś rozpoczynać żadnych nowych projektów z ext/mysql już, gdy masz lepsze rozszerzenie na początek.

zobaczyć również http://blog.ulf-wendel.de/2012/php-mysql-why-to-upgrade-extmysql/

Źródło

2011-08-26 15:10:01 Gordon

Mogę już robić transakcje (czy to wolno): http://stackoverflow.com/questions/2708237/php-mysql-transakcje- przykłady i kod wydaje się działać dobrze – Neal

Obsługa OOP jest kulawa, przygotowane oświadczenia są wolne, wiele instrukcji jest podatnych na wstrzykiwanie, a wbudowany serwer jest śmieszny. Szczerze mówiąc, nie ma żadnych rzeczywistych korzyści. –

@Gordon, ** będzie ** należy zastąpić ** jest bardzo prawdopodobne, **. Nie możesz powiedzieć, co ** ** stanie się w PHP-land, tak jak nie możemy. – salathe

Moim zdaniem, korzyści z MySQLi jest, gdy jest używany w sposób zorientowany obiektowo, a także z przygotowanych sprawozdań. Dostajesz z niego dodatkową wszechstronność, używając także stylu proceduralnego, np. Ładnych funkcji otoki wokół obsługi transakcji, ale uważam, że nie wystarcza, aby usprawiedliwić, chyba że przepisałeś dużo kodu, aby z nich skorzystać.

Jeśli miałbyś podjąć wysiłek, aby przekonwertować kod OO lub przygotowane instrukcje, możesz równie dobrze zamienić się na bardziej elastyczny PDO zamiast na MySQLi.

Aktualizacja Jan 2013

Wystarczy znaleźć tę starą odpowiedź, aw sierpniu 2011 r komentarza wątku poniżej Powiedziałem, że nie było warto przekonwertować mysql_query() połączeń do mysqli_query() nieobecny towarzyszący przenieść się do przygotowanych sprawozdań. Teraz konieczne jest rozpoczęcie pracy w tym kierunku, ponieważ rozszerzenie mysql_*() jest przestarzałe od PHP 5.5 i ostatecznie zostanie usunięte.

Źródło

2011-08-26 15:00:53

Tak, ale czy warto czasu na przełączanie aplikacji ma ponad 500 połączeń 'mysql_ *'? – Neal

@Neal Powiedziałbym, że tak nie jest, chyba że musisz użyć ulepszonych wrapperów MySQLi dookoła transakcji commit/rollback, itp. –

PDO to dobry wybór, ale na wspólnym serwerze nie możesz użyć suhosin.sql.user_prefix http : //www.hardened-php.net/suhosin/configuration.html#suhosin.sql.user_prefix – corretge

Moim zdaniem, nie powinieneś używać funkcji mysql_ * bezpośrednio w swojej logice. Powinieneś napisać opakowanie. Więc jeśli chcesz przełączyć mysql_* na mysqli_*, wystarczy zmienić kod opakowania.

Źródło

2011-08-26 15:08:15 xdazz

? jak to zrobić i jak mogę zapobiec błędom w całym kodzie? – Neal

Zapobieganie błędom zależy od testu. – xdazz

huh? co to znaczy? – Neal

MySQLi ma pewne zalety wydajnościowe w stosunku do MySQL. Właściwie zaleca się używanie MySQLi zamiast MySQL. Możesz także wykonać styl proceduralny.

Można utworzyć nowy oddział aplikacji i zmienić kod na funkcje mysqli_*. To powinno być całkiem proste, a podczas tego przeglądu przeglądu kodu dostępu do bazy danych, które mogą pomóc w kontynuowaniu po przejściu na mysqli, aby kontynuować refaktoryzacji. Jeśli to wszystko za dużo kłopotów, już korzystasz z ulepszonej wersji biblioteki klienta w kodzie dostępu do bazy danych.

Źródło

2011-08-26 15:09:04 hakre

"MySQLi ma pewne zalety wydajnościowe w porównaniu z MySQL"? To jest wiadomość, skąd masz te informacje? Zawsze wydaje się, że jest odwrotnie. – Pacerier

Wycofanie ext/mysql nie jest plotka.

Jednak to nie jest twój prawdziwy problem.

Głównym problemem jest to, że używasz nagich wywołań API w całym kodzie zamiast używać inteligentnej biblioteki do obsługi zapytań SQL.

Lepiej zacznij tworzyć taką bibliotekę lub przygotuj ją, a następnie przepisz swój kod, aby korzystać z jego połączeń.

Nie widzisz, że to wszystko powtarza się rzeczy

$res=mysql_query("SELECT STUFF"); 
while($row = mysql_fetch){ 
    $var=$row['col']; 
}

jest niewiarygodnie nudne?
dlaczego nie użyć jakiegoś jednego-liner jak

$data = $db->getRow("SELECT stuff");

który jest krótszy i może mieć wiele funkcji, takich jak rejestrowanie zapytań, liczenie, debugowanie, obsługi błędów i takie tam?

I, jako efekt uboczny używania takiej biblioteki, jedynym miejscem, w którym trzeba będzie zmienić wszelkie wywołania API, będzie tylko ten kod biblioteki.

Źródło

2011-08-26 15:10:34

Jeśli masz tyle połączeń, proponuję rozpocząć od zaimplementowania (wybrania lub zbudowania) warstwy abstrakcji dla wywołań baz danych, a następnie przekonwertować.

Największą korzyścią (istotną) w moim podobnym ćwiczeniu był fakt, że mysqli oferuje sparametryzowane instrukcje pozwalające pozostawić mysql_real_escape_string itp. W tyle.Ale mapa z jednego do drugiego nie jest prawie jeden do jednego.

Źródło

2011-08-26 15:11:33 dkretz

jesteś drugim, który mówi, że używa "warstwy abstrakcji", jak mam to zrobić? – Neal

CHNP jest warstwą abstrakcji. Oferuje klasę z metodami i właściwościami, które są bliższe temu, co dzieje się w języku proceduralnym, a zazwyczaj są bogatsze i bardziej spójne koncepcyjnie. Lub na przykład ten, który napisałem, jest klasą, z której robię wszystko, czego potrzebuję, z $ db-> SqlExecute ($ sql), SqlRows ($ sql), SqlOneRow ($ sql), SqlExists ($ sql) i SqlOneValue ($ sql). Po prostu zamyka wzory, z którymi możesz się cieszyć. Moje osobiste preferencje to bardzo cienki filtr między SQL i PHP. – dkretz

@Neal PDO jest bardzo kiepską warstwą abstrakcji. Lepiej znaleźć coś bardziej niezawodnego. –

Porada: Jeśli zamierzasz zrobić przełącznik, nie przełączaj się na mysqli, zamiast tego przełącz się na używanie PDO. Jeśli musisz przełączyć się na mysqli, upewnij się, że używasz go w PHP OO. Nie używaj mysqli OO i starego mysql w tym samym czasie lub starego mysql i PDO w tym samym czasie, chyba że lubisz niespodziewane zgniatanie połączenia.

Źródło

2011-08-26 15:40:34 Ray

Przełącz się na mysqli lub zostań z mysql?

Odpowiedz

Powiązane problemy