[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

[Kshyhoo]

Zasada chyba taka:

[PHP] pobierz, plaintext 
$wynik=mysql_query("SELECT * FROM tabela WHERE dane='$szukane'");
 
if (mysql_num_rows($wynik)>0) {
  echo "Podany tekst już istnieje w bazie!";
}
if (mysql_num_rows($wynik)==0) {
  mysql_query("INSERT INTO tabela (dane) VALUES ('$szukane')");
  echo "Podany tekst został dopisany!";
}
[PHP] pobierz, plaintext 

[casperii]

Zasada chyba taka:

[PHP] pobierz, plaintext 
$wynik=mysql_query("SELECT * FROM tabela WHERE dane='$szukane'");
 
if (mysql_num_rows($wynik)>0) {
  echo "Podany tekst już istnieje w bazie!";
}
if (mysql_num_rows($wynik)==0) {
  mysql_query("INSERT INTO tabela (dane) VALUES ('$szukane')");
  echo "Podany tekst został dopisany!";
}
[PHP] pobierz, plaintext 

@Kshyhoo nie rozumiem, jak to ma się tyczyć mojego zapytania?
Co za różnica czy ja sobie dam:
$wynik=mysql_query("SELECT * FROM tabela WHERE dane='$szukane'");
czy
$wynik="SELECT * FROM tabela WHERE dane='$szukane'";
$res = mysql_query($wynik);
?

Dodatkowo, czemu taki preg_match uważa że adres@domena jest poprawny? powinno przejść minimum przy adres@domena KROPKA PL/DE itd

if(!preg_match("/^([a-zA-Z0-9])+([a-zA-Z0-9\._-])*@([a-zA-Z0-9_-])+([a-zA-Z0-9\._-]+)+$/", $email))

[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.

[casperii]

Ok, żeby nie pisać kolejnego tematu, to korzystając sytuacji zadam pytanie, czy taka forma jest traktowana / dobra / optymalna:

[PHP] pobierz, plaintext 
$result = "SELECT * FROM `table` WHERE `cos`='$cos'"
mysql_query($result);
if ($error = mysql_error()) die('Błąd:' . $error);
[PHP] pobierz, plaintext 

oraz... jak powinien wyglądać dobrze zabezpieczony kod żeby uniknąć sql injection. Czy tak jest dobrze: ?

[PHP] pobierz, plaintext 
function checkValues($value)
{
	 $value = trim($value);
	if (get_magic_quotes_gpc()) {
		$value = stripslashes($value);
	}
	 $value = strtr($value,array_flip(get_html_translation_table(HTML_ENTITIES)));
	 $value = strip_tags($value);
	$value = mysql_real_escape_string($value);
	return $value;
 
}
 
$cos = checkValues($_POST['cos']); 
[PHP] pobierz, plaintext 

oraz przy wyświetlaniu z bazy na strone :

[PHP] pobierz, plaintext 
function zabezpiecz($str){
return mysql_real_escape_string(htmlspecialchars(strip_tags($str)));
}
 
print(''.zabezpiecz($row['cos']).''); 
[PHP] pobierz, plaintext 

A może już dawać jakąś funkcję już na poziomie połączenia z bazą? Albo pokazując rowa? (IMG:style_emoticons/default/oneeyedsmiley02.png)
Dodatkowo co lepiej stosować print czy echo ? Czy powinno być print() czy lepiej print '' ? Pytania banalne , ale jak już programować to chyba eliminując błędy.

[b4rt3kk]

Błąd połączenia z bazą danych, w wielu aplikacjach oznacza, że nie może ona poprawnie działać, więc owszem, mógłbyś w tym momencie dać die i błąd sql, ale wtedy user również ujrzy treść tego błędu, co nie jest wskazane (lepiej zapisz go sobie do pliku tekstowego, wraz z czasem wystąpienia, linią, plikiem, itd. żeby mieć do późniejszego wglądu). Kolejna sprawa, zablokujesz dalsze wykonywanie kodu, tak więc np. zamiast wyświetlić przyjazny dla usera komunikat, opakowany w trochę HTML-a, zobaczy prawdopodobnie białą stronę z treścią błędu (zależy jak masz zbudowaną aplikację i gdzie masz ten die). Lepiej wyrzucić wyjątek i obsłużyć go odpowiednio w widoku.

Najlepiej się zabezpieczyć poprzez stosowanie zapytań z placeholderami, gdzie odpowiednia biblioteka zajmie się podstawieniem wartości.

A tutaj przesadziłeś:

[PHP] pobierz, plaintext 
function zabezpiecz($str){
return mysql_real_escape_string(htmlspecialchars(strip_tags($str)));
}
[PHP] pobierz, plaintext 

Zdecyduj się na jedną funkcję, osobiście polecam htmlspecialchars, wystarczy. I tak, stosujesz ją dopiero przy wyświetlaniu treści userowi.

Nie ma w zasadzie żadnej większej różnicy pomiędzy echo a print, stosuj jak Ci wygodnie, nie ma to większego znaczenia. Ja osobiście preferuję echo.

[robertpiaty]

Odnośnie pierwszego wpisu to żeby było jedno zapytanie to można spróbować zrobić subquery, coś w tym stylu

[SQL] pobierz, plaintext 
SELECT u.id_user, u.email, e.count FROM (SELECT id_user, email FROM users WHERE id_user = $idUser) AS u, (SELECT count(email) AS count FROM users WHERE email = $email)
[SQL] pobierz, plaintext 

Nie testowałem tego czy to pytanie zadziała ale mi chodziło o sam pomysł. Nie wiem też jak z wydajnością takiego zapytania.

Poniższa forma jest optymalna.

[SQL] pobierz, plaintext 
$result = "SELECT * FROM `table` WHERE `cos`='$cos'"
[SQL] pobierz, plaintext 

Jeśli się da to lepiej stosować "=" niż "like". Dodatkowo pamiętaj o indeksie na kolumnie `cos`. Dodatkowo jak masz dużo kolumn w tabeli a potrzebujesz dane np z dwóch to lepiej zamiast gwiazdki wymienić kolumny z których chesz pobrać dane.

Aby zabezpieczyć przed sql injection używaj mysqli bind_param i prepare http://php.net/manual/en/mysqli.quickstart...-statements.php

Ten post edytował robertpiaty 23.05.2015, 11:04:52

[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

[casperii]

A to ja mam zrobione , że w razie błędu 404, 500 , 503 użytkownik dostaje ładnie komunikat. Informacja się zapisuje w logu, a ja dostaje dodatkowo maila.
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ę.

Chodzi o to by pokazać mi jak nawiązać połączenie, wybrać tabelę, dodać rekord, updatować rekord i wyświetlić wynik. Mam na myśli poprawne tego wykonanie, a nie tutorialowe gdzie człowiek chcący się nauczyć powiela błędy.

Drugie pytanie, czy swoje serwisy opieracie na templatach czy walicie w htmla czysty php?

Ten post edytował casperii 23.05.2015, 11:51:11

[robertpiaty]

Silnym i jak dla mnie wystarczającym argumentem za mysqli jest bezpieczeństwo.

Tu masz przykłady jak to używać http://php.net/manual/en/mysqli.quickstart...-statements.php To nie są tutoriale tylko dokumentacja z przykładami.

Dobrym zwyczajem jest używanie MVC czyli oddzielenie logiki, komunikacji z bazą i kodu HTML. Wyobraź sobie sytuację kiedy masz napisaną całą stronę w jednym pliku php (mix PHP, js i html) i nagle ktoś Ci przychodzi i mówi że trzeba pozmieniać wygląd strony. Gdy masz oddzielony HTML od PHP zdecydowanie pójdzie Ci to łatwiej i szybciej

[casperii]

Silnym i jak dla mnie wystarczającym argumentem za mysqli jest bezpieczeństwo.

Tu masz przykłady jak to używać http://php.net/manual/en/mysqli.quickstart...-statements.php To nie są tutoriale tylko dokumentacja z przykładami.

Dobrym zwyczajem jest używanie MVC czyli oddzielenie logiki, komunikacji z bazą i kodu HTML. Wyobraź sobie sytuację kiedy masz napisaną całą stronę w jednym pliku php (mix PHP, js i html) i nagle ktoś Ci przychodzi i mówi że trzeba pozmieniać wygląd strony. Gdy masz oddzielony HTML od PHP zdecydowanie pójdzie Ci to łatwiej i szybciej

Czy zatem templaty czy coś innego ?

[robertpiaty]

Zależy jaką stronę tworzysz. Nie ma sensu z armaty strzelać do wróbla. Jeśli jest to naprawdę jakaś prosta strona to wystarczą templaty. Jeśli już jednak jest to większa strona czy też nawet CRM to już tylko jakiś framework który będzie najlepiej odpowiadał potrzebom strony, a Tobie ułatwi pisanie takiej strony.

[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.

[salfunglandyare]

wracajac do tematu:

[SQL] pobierz, plaintext 
SELECT count(`id_user`) FROM `users` WHERE `id_user`<>'$id_user' AND email = '$email';
[SQL] pobierz, plaintext 

to daje Ci 0 - email nie istnieje w bazie dla innego użytkownika, >0 (1), jeśli istnieje w bazie dla innego użytkownika niż $id_user, a z pierwszego posta wnioskuje, ze o takie cos Ci chodzi

[aachi]

Salfunglandyare chyba odpowiedział już na twoje pytanie. Ja tylko troszkę zmodyfikuję jego zapytanie:

[SQL] pobierz, plaintext 
SELECT id_user FROM users WHERE email = '$email' AND id_user<>'$id_user' LIMIT 1
[SQL] pobierz, plaintext 

wykona się ciutkę szybciej...


No, a jeśli dosłownie chcesz mieć jedno zapytanie, ale działające tak samo jak w twoim pierwszym poscie:

[PHP] pobierz, plaintext 
$result="SELECT id_user, email FROM users WHERE id_user='$id_user' OR email='$email' LIMIT 2";
$sql = mysql_query($result);
if ($sql) {
   while ($w=mysql_fetch_assoc($sql)) { 
      if ($w['id_user']==$id_user) $obecnyMail=$w;
      else $czyZajety=true;
   }
   unset ($w);
}
else {
   $status = "error";
   $message = 'Błąd bazy danych. Zapytanie: '.$result.'; Błąd: '.mysql_error();
} 
 
if ($czyZajety) {
   $status = "error";
   $message = "Wpisany adres e-mail jest już zajęty.";
}
[PHP] pobierz, plaintext 

Swoją drogą widać, że jesteś na początku nauki I, że korzystasz z bardzo starych I błędnych materiałów:
Te nieszczęsne " or die('zapytanie :'.$result.' blad:'.mysql_error()); " powinieneś mieć w linijkach o jeden niżej, by miały jakikolwiek sens. Czyli: $sqlObecny = mysql_query($resultObecny) or die('zapytanie :'.$resultObecny.' blad:'.mysql_error());