[MySQL]Czy da się 2 zapytania do bazy zrobić w 1 zapytanie?, czy jest to możliwe? Opcje

[casperii]

Czy da się to zrobić jednym zapytaniem ?

[PHP] pobierz, plaintext 
$email = checkValues($_POST['email']);
 
$resultObecny = "SELECT `id_user`, `email` FROM `users` WHERE `id_user`='$id_user'"  or die('zapytanie :'.$result.' blad:'.mysql_error()); 
		$sqlObecny = mysql_query($resultObecny);
		$obecnyMail = mysql_fetch_array($sqlObecny,MYSQL_ASSOC);
		$staryMail = $obecnyMail['email'];
 
		if($email != $staryMail){
			$resultEmail = "SELECT `email` FROM `users` WHERE `email`='$email'"  or die('zapytanie :'.$result.' blad:'.mysql_error()); 
			$sqlEmail = mysql_query($resultEmail); 
			if(mysql_num_rows($sqlEmail)!=0){
				$status = "error";
				$message = "Wpisany adres e-mail jest już zajęty.";
			}
		}
[PHP] pobierz, plaintext 

Czyli chodzi o to by nie updatowało mi maila który jest już w bazie. Tylko sprawdzam ,czy taki email jest w bazie , jeżeli nie ma jest możliwość wpisania innego i zaktulizowanie go.
Reasumując: w pierwszy zapytaniu, sprawdzam jaki adres email użytkownik miał. Jeżeli podał w poscie inny adres niż miał w bazie następuje drugie zapytanie i szukanie czy taki adres jaki podał poprzez post istnieje w bazie. Jeżeli nie istnieje przechodzimy dalej, jeżeli istnieje wywali error.

Ten post edytował casperii 22.05.2015, 20:37:14

[mmmmmmm]

[PHP] pobierz, plaintext 
$resultEmail = "SELECT `email` FROM `users` WHERE `email`='$email'"  or die(mysql_error()); 
[PHP] pobierz, plaintext 

WTF??
Co może się nie udać w podstawieniu do zmiennej, że robisz die() (IMG:style_emoticons/default/questionmark.gif)

[b4rt3kk]

[PHP] pobierz, plaintext 
$resultEmail = "SELECT `email` FROM `users` WHERE `email`='$email'"  or die(mysql_error()); 
[PHP] pobierz, plaintext 

WTF??
Co może się nie udać w podstawieniu do zmiennej, że robisz die() (IMG:style_emoticons/default/questionmark.gif)

Możesz próbować przykładowo obiekt lub tablicę, wstawić jako string. (IMG:style_emoticons/default/smile.gif)

[Xelah]

Ustaw pole email jako unique i możesz po prostu strobić zwykły update bez sprawdzania czy obecny email się zmienił i czy nowy już istnieje. Jeśli email jest taki jak był wcześniej, to MySQL niczego nie będzie aktualizował. Jeśli jest inny, ale nie jest unique, to od razu dostaniesz bład z bazy.

Możesz próbować przykładowo obiekt lub tablicę, wstawić jako string. :)

Możesz, ale

[PHP] pobierz, plaintext 
or die()
[PHP] pobierz, plaintext 

niczego w tym przypadku nie da i nie zmieni.

[PHP] pobierz, plaintext 
$array = array(1,2);
$string = "tutaj tekst ". $array or die ("Upss...");
 
$obj = new \stdClass();
$string = "tutaj tekst ". $obj or die ("Upss...");
[PHP] pobierz, plaintext 

Kod

<br />
<b>Notice</b>:  Array to string conversion in <b>[...][...]</b> on line <b>2</b><br />
<br />
<b>Catchable fatal error</b>:  Object of class stdClass could not be converted to string in <b>[...][...]</b> on line <b>5</b><br />

Nawet gdyby die działało, to wyświetlanie tam ostatniego błędu z SQL ma rzeczywiście sens... Logika nie do obalenia :D

[b4rt3kk]

Ustaw pole email jako unique i możesz po prostu strobić zwykły update bez sprawdzania czy obecny email się zmienił i czy nowy już istnieje. Jeśli email jest taki jak był wcześniej, to MySQL niczego nie będzie aktualizował. Jeśli jest inny, ale nie jest unique, to od razu dostaniesz bład z bazy.




Możesz, ale

[PHP] pobierz, plaintext 
or die()
[PHP] pobierz, plaintext 

niczego w tym przypadku nie da i nie zmieni.

[PHP] pobierz, plaintext 
$array = array(1,2);
$string = "tutaj tekst ". $array or die ("Upss...");
 
$obj = new \stdClass();
$string = "tutaj tekst ". $obj or die ("Upss...");
[PHP] pobierz, plaintext 

Kod

<br />
<b>Notice</b>:  Array to string conversion in <b>[...][...]</b> on line <b>2</b><br />
<br />
<b>Catchable fatal error</b>:  Object of class stdClass could not be converted to string in <b>[...][...]</b> on line <b>5</b><br />

Nawet gdyby die działało, to wyświetlanie tam ostatniego błędu z SQL ma rzeczywiście sens... Logika nie do obalenia (IMG:style_emoticons/default/biggrin.gif)

Nie twierdzę, że to ma sens, ale że może czasem się coś nie udać przy wstawianiu zmiennych do stringa. (IMG:style_emoticons/default/smile.gif)

Ten post edytował b4rt3kk 23.05.2015, 09:32:01

[Xelah]

Nie twierdzę, że to ma sens, ale że może czasem się coś nie udać przy wstawianiu zmiennych do stringa. :)

Tak, ale "or die" nigdy tego nie wykryje. Widzę, że chyba nie do końca rozumiesz, jak działa "or die". Ale skoro jesteśmy w dziale "Przedszkole" do podejdziemy do tego łopatologicznie.

"or" to operator boolowski. Aby to, co jest prawym argumentem zostało wykonane, to po lewej musi być coś, co da nam "false". Na przykład może to być funkcja. Jeśli zwraca "false", "null", "0" lub pusty string, to PHP wykona to, co jest prawym argumentem "or".

Notice czy fatal exception nie zwracają niczego. A więc i "die" nigdy nie ozstanie wykonane.
Jedyna sytuacja, gdzie lewy argument może ewaluować do false jest coś takiego:

[PHP] pobierz, plaintext 
$string = "" or die("Upss...");
[PHP] pobierz, plaintext 

Ale w przykładach autora string nigdy nie będzie pusty i die nigdy nie będzie wykonane. Bez względu na to, co się stanie.

Zabezpieczenie przed wkładaniem nie stringów do stringa trzeba zrobić ręcznie a nie czekać aż kod się jakoś sypnie.

[b4rt3kk]

Tak, ale "or die" nigdy tego nie wykryje. Widzę, że chyba nie do końca rozumiesz, jak działa "or die". Ale skoro jesteśmy w dziale "Przedszkole" do podejdziemy do tego łopatologicznie.

"or" to operator boolowski. Aby to, co jest prawym argumentem zostało wykonane, to po lewej musi być coś, co da nam "false". Na przykład może to być funkcja. Jeśli zwraca "false", "null", "0" lub pusty string, to PHP wykona to, co jest prawym argumentem "or".

Notice czy fatal exception nie zwracają niczego. A więc i "die" nigdy nie ozstanie wykonane.
Jedyna sytuacja, gdzie lewy argument może ewaluować do false jest coś takiego:

[PHP] pobierz, plaintext 
$string = "" or die("Upss...");
[PHP] pobierz, plaintext 

Ale w przykładach autora string nigdy nie będzie pusty i die nigdy nie będzie wykonane. Bez względu na to, co się stanie.

Zabezpieczenie przed wkładaniem nie stringów do stringa trzeba zrobić ręcznie a nie czekać aż kod się jakoś sypnie.

Jeszcze raz, nie nadinterpretuj mojej wypowiedzi, ja nic nie wspominałem o or die, cały czas mówię tylko co się może nie udać przy podstawianiu stringa, o or die słowem nie wspomniałem. Odpowiedziałem tylko na pierwszą część Twojego pytania parę postów wyżej nie zwracając uwagi na or die. Po co się w ogóle tym zajmować? Or die można stosować tylko przy debugowaniu, już przy aplikacji produkcyjnej jest to niezbyt wygodne rozwiązanie.

[Xelah]

Jeszcze raz, nie nadinterpretuj mojej wypowiedzi, ja nic nie wspominałem o or die, cały czas mówię tylko co się może nie udać przy podstawianiu stringa, o or die słowem nie wspomniałem. Odpowiedziałem tylko na pierwszą część Twojego pytania parę postów wyżej nie zwracając uwagi na or die. Po co się w ogóle tym zajmować? Or die można stosować tylko przy debugowaniu, już przy aplikacji produkcyjnej jest to niezbyt wygodne rozwiązanie.

...
http://forum.php.pl/index.php?showtopic=24...t&p=1159106

Ja niczego nie interpretuję. Po prostu czytam ze zrozumieniem.

A "or die" nie używa się nigdy. Do debugowania to jest xdebug. A nie "die" czy "var_dump".

...

Co do niespodziewanego zachowania systemu powinieneś rzucaj wyjątek. To, jak twoja aplikacja go obsłuży to już inna sprawa. Czy będziesz miał jakieś logowanie błędów, albo ładną stronę 500 czy 503 dla użytkownilka to już decyzja aplikacji a nie fragmentu kodu, gdzie nastąpił błąd.

Zasada jest prosta. Jeśli wywołujesz metodę, która ma coś zrobić, albo na przykład zwrócić rekord z bazy a nie jest tego w stanie zrobić z dowolnego powodu, to rzucasz wyjątkiem. Nie zwracasz null czy false. Zawsze wyjątek. Kod wywołujący będzie wtedy czysty, bo nie musisz się tam martwić o to, co zrobić jak dostaniesz null czy false.

Jeśli chodzi o SQL injection (ale nie tylko) to zainteresuj się PDO i bindParam czy bindValue.

[b4rt3kk]

...
http://forum.php.pl/index.php?showtopic=24...t&p=1159106

Ja niczego nie interpretuję. Po prostu czytam ze zrozumieniem.

A "or die" nie używa się nigdy. Do debugowania to jest xdebug. A nie "die" czy "var_dump".



Co do niespodziewanego zachowania systemu powinieneś rzucaj wyjątek. To, jak twoja aplikacja go obsłuży to już inna sprawa. Czy będziesz miał jakieś logowanie błędów, albo ładną stronę 500 czy 503 dla użytkownilka to już decyzja aplikacji a nie fragmentu kodu, gdzie nastąpił błąd.

Zasada jest prosta. Jeśli wywołujesz metodę, która ma coś zrobić, albo na przykład zwrócić rekord z bazy a nie jest tego w stanie zrobić z dowolnego powodu, to rzucasz wyjątkiem. Nie zwracasz null czy false. Zawsze wyjątek. Kod wywołujący będzie wtedy czysty, bo nie musisz się tam martwić o to, co zrobić jak dostaniesz null czy false.

Jeśli chodzi o SQL injection (ale nie tylko) to zainteresuj się PDO i bindParam czy bindValue.

Nie "się używa", tylko Ty używasz. Mi die i var_dump w zupełności wystarcza.

Poza tym to od kiedy aplikacja decyduje za siebie? To programista musi przewidzieć pewne zachowania oraz to jak je obsłużyć. To że sobie rzucisz wyjątkiem nie znaczy, że aplikacja "magicznie" go wyłapie i obsłuży wedle własnego uznania.

Ten post edytował b4rt3kk 23.05.2015, 11:41:44

[Xelah]

Nie "się używa", tylko Ty używasz. Mi die i var_dump w zupełności wystarcza.

Idąc tym tokiem rozumowania można powiedzieć, że JSON-a można używać regexpa bo przecież "mi wystarcza". Albo do xml-a też regexp, no bo "mi wystarcza". SOPA też można samemu na socketach napisać, i XML-a do niego w plain PHP zrobić, bo "mi wystarcza".
Tu nie chodzi o to, co komu wystarcza, a o to, że jeśli w danym języku masz dedykowane narzędzie to czegoś, które na dodatek jest kilka razy skuteczniejsze i efektywniejsze to się go używa. Nie chcesz go używać to nie. Nikt Cię zmuszać nie będzie. Ale nie sugeruj komuś, kto pyta o poradę takich rzeczy. Tylko tyle.

Poza tym to od kiedy aplikacja decyduje za siebie? To programista musi przewidzieć pewne zachowania oraz to jak je obsłużyć. To że sobie rzucisz wyjątkiem nie znaczy, że aplikacja "magicznie" go wyłapie i obsłuży wedle własnego uznania.

Aplikacja zawsze decyduje sama za siebie. Metoda sama w sobie nie podejmuje decyzji o tym, jak błąd ma być obsłużony, bo to nie jej działka. Słyszałeś o czymś takim jak "Separation of concerns" czy "Single responsibility"? Medota łącząca z bazą ma za zadanie połączyć się z bazą. Jak nie może to rzuca wyjątek. To programista, w zależności od wielu czyników musi zdecydować gdzie i jak obsłużyć ten wyjątek.

Na razie nie chciałbym przechodzi na mysqli , chociaż nie ukrywam ,że jeśli ktoś by mi podpowiedział na przykładzie w taki sposób abym zrozumiał i podał silne argumenty prócz tego że "idzie nowe" to jestem wstanie zmienić swoją decyzję.

Wydaje mi się, że to jest całkiem dobry argument:

This extension is deprecated as of PHP 5.5.0, and is not recommended for writing new code as it will be removed in the future.

Dla własnej wygody :)

Tutaj masz jeszcze fajny artykuł na ten temat:
https://blog.udemy.com/mysql-vs-mysqli/

To nie jest tylko "Idzie nowe", ale racze idzie lepsze. Skoro masz dzisiaj wybów, to wybierze coś bardziej przyszłościowego.

A jeśli już pytasz o porady to jeszcze chciałbym namienić jedno. Nie wiąż swojej aplikacji mocno z bazą danych. Pamiętaj, że samo persistence to jest tylko drobny szczegół, bez którego można się obejsć całkiem długo. Nie zaczynaj od bazy, bo zły kierunek. Zacznij od działającego obiektowego kodu. To, jak będziesz zapisywał te obiekty i jak odczytywał to już inna kwestia. Dzięki temu nie będzie musiał naginać logiki do struktury bazy.

[b4rt3kk]

Idąc tym tokiem rozumowania można powiedzieć, że JSON-a można używać regexpa bo przecież "mi wystarcza". Albo do xml-a też regexp, no bo "mi wystarcza". SOPA też można samemu na socketach napisać, i XML-a do niego w plain PHP zrobić, bo "mi wystarcza".
Tu nie chodzi o to, co komu wystarcza, a o to, że jeśli w danym języku masz dedykowane narzędzie to czegoś, które na dodatek jest kilka razy skuteczniejsze i efektywniejsze to się go używa. Nie chcesz go używać to nie. Nikt Cię zmuszać nie będzie. Ale nie sugeruj komuś, kto pyta o poradę takich rzeczy. Tylko tyle.

Wskaż mi proszę, gdzie ja komuś sugerowałem używanie die czy var_dumpa? Od kiedy to xdebug jest częścią kompilacji php? Nie przesadzasz trochę? Do JSON, XML czy SOAP php ma wbudowane klasy i funkcje. Xdebug do nich nie należy.

Aplikacja zawsze decyduje sama za siebie. Metoda sama w sobie nie podejmuje decyzji o tym, jak błąd ma być obsłużony, bo to nie jej działka. Słyszałeś o czymś takim jak "Separation of concerns" czy "Single responsibility"? Medota łącząca z bazą ma za zadanie połączyć się z bazą. Jak nie może to rzuca wyjątek. To programista, w zależności od wielu czyników musi zdecydować gdzie i jak obsłużyć ten wyjątek.


Wydaje mi się, że to jest całkiem dobry argument:

Dla własnej wygody (IMG:style_emoticons/default/smile.gif)

Tutaj masz jeszcze fajny artykuł na ten temat:
https://blog.udemy.com/mysql-vs-mysqli/

To nie jest tylko "Idzie nowe", ale racze idzie lepsze. Skoro masz dzisiaj wybów, to wybierze coś bardziej przyszłościowego.

A jeśli już pytasz o porady to jeszcze chciałbym namienić jedno. Nie wiąż swojej aplikacji mocno z bazą danych. Pamiętaj, że samo persistence to jest tylko drobny szczegół, bez którego można się obejsć całkiem długo. Nie zaczynaj od bazy, bo zły kierunek. Zacznij od działającego obiektowego kodu. To, jak będziesz zapisywał te obiekty i jak odczytywał to już inna kwestia. Dzięki temu nie będzie musiał naginać logiki do struktury bazy.

A co ja wcześniej napisałem? Sparafrazowałeś moje słowa...

To programista musi przewidzieć pewne zachowania oraz to jak je obsłużyć.

Jeszcze raz mówię, to że rzucisz wyjątek, to nie znaczy, że z automatu zostanie on obsłużony. Aplikacja nigdy nie decyduje sama za siebie, chyba że AI.

[PHP] pobierz, plaintext 
class test {
  public function __construct() {
    throw new Exception('Wyjątek!!!');
  }
}
 
$t = new test();
[PHP] pobierz, plaintext 

Jaką decyzję aplikacja podejmie w tym przypadku? Rzuciłem wyjątkiem i co dalej?

[Xelah]

Wskaż mi proszę, gdzie ja komuś sugerowałem używanie die czy var_dumpa?

Or die można stosować tylko przy debugowaniu, już przy aplikacji produkcyjnej jest to niezbyt wygodne rozwiązanie."

A to nie jest sugestia? Jak dla mnie "Or die można stosować" niestety jest sugestią.

Od kiedy to xdebug jest częścią kompilacji php? Nie przesadzasz trochę? Do JSON, XML czy SOAP php ma wbudowane klasy i funkcje. Xdebug do nich nie należy.

A co to ma do rzeczy? Czy sugerujesz, że programista PHP to pół*****k, który nie potrafi zainstalować rozszerzenia do PHP? Czyli jak coś robię w PHP to powinienem używać tylko rozszerzeń dostępnych out of the box? To chyba Ty nieco teraz przesadzasz. Instalacja xdebug i konfiguracja to jednorazowy koszt około 20 minut (łącznie z konfiguracją pod IDE i CLI). Przepraszam, ale dla mnie to nie jest argument.

Jeszcze raz mówię, to że rzucisz wyjątek, to nie znaczy, że z automatu zostanie on obsłużony. Aplikacja nigdy nie decyduje sama za siebie, chyba że AI.

Nie zrozumieliśmy się. Dalej twierdzę, że aplikacja, jako całość jest odpowiedzialna za obsługę wyjątku. A aplikację napisał programista. Suma summarum to programista jest odpowiedzialny za dodanie tej obsługi - to chyba jest oczywiste. Chodzi tylko o to, gdzie ta obsługa powinna się znaleźć. Ja uważem, że przenigdy nie w funkcji, w której wystąpił problem, bo to nie dość, że skomplikowane to jeszcze proszenie się o kłopoty.

Wiadomo, że inaczej wygląda obsługa wyjątku we fragmencie webowym a inaczej w tasku odpalanym z linii poleceń. Cedowanie odpowiedzialności na metodę, gdzie wystąpił problem jest nielogiczne, bo zmusza każdą metodę, gdzie problem może wytąpić, do znajomości pełnego kontekstu aplikacji i logiki biznesowej. Warstwa aplikacji, która w jakiś sposób wykorzystuje metodę, w której wystąpił błąd powinna się martwić co z tym fantem zrobić. Czy w ogóle coś ma robić, czy może przepuścić wyjątek jeszcze wyżej. Cały czas piszę o aplikacji, bo to to w końcu aplikacja wywołuje te czy inne metody a nie programista. Programista przecież nie siedzi nad procesorem i nie czeka aż poleci wyjątek...

Tylko tyle. Ja nie sugeruję ani AI ani magii.