[MySQL][PHP]foreach i zmienne do mysql'a Opcje

[apkc]

Wiatm!
Za pomocą funkcji foreach, otrzymuję tablice (niewiem ilu elementową) i mam takie pytanko jak pobrać z bazy danych te wiersze w których $id jest równa wartością z tablicy?

Np. funkcja zwróci mi tablicę

[PHP] pobierz, plaintext 
Array(1,3,5,7,)
[PHP] pobierz, plaintext 

Więc chcępobrać z bazy wiersze w których

[PHP] pobierz, plaintext 
$id=1;
$id=3;
$id=5;
$id=7;
[PHP] pobierz, plaintext 

Jak ma poprawnie być zbudowana taka pentla?

[Ellington]

Podmien sobie, co trzeba.

Kod

foreach($array as $element)
{

   // SELECT * FROM tabela WHERE id = $element
   // pobrane dane wpisz np. w tabele $result[]

}

[apkc]

Coś mi to nie wychodzi!
Mam taki kodzik

[PHP] pobierz, plaintext 
$chks = array();
foreach($_GET as $k =>  $v) {
 
  if( substr( $k, 0, 4) == 'chk-'){
	$chks[]=$v;
	}
 
}
[PHP] pobierz, plaintext 

I teraz potrzebuję wstawić pętle, która zczytane wartości podstawi mi np. do

[PHP] pobierz, plaintext 
$tablica_wyników=Array(1,2,3,4);
[PHP] pobierz, plaintext 

Czy możesz na tym przykładzie pokazać jak ta pętla ma wyglądać?

[melkorm]

Zainteresuj się

implode

i

MySql'owym

Kod

IN

[apkc]

Dzięki za podpowiedź! Zrobiłem coś takiego:

[PHP] pobierz, plaintext 
$comma_separated = implode(",", $chks); 
$zapytanie = "SELECT `ph` FROM `analizys` WHERE `kj` IN ('$comma_separated')";
  echo mysql_error();
	$wykonaj = mysql_query ($zapytanie);
	while($wiersz=mysql_fetch_array ($wykonaj))
	{
	$ph=$wiersz['ph'];
	}
[PHP] pobierz, plaintext 

Funkcja

[PHP] pobierz, plaintext 
$comma_separated = implode(",", $chks); 
[PHP] pobierz, plaintext 

Zwraca mi np. cztery wartości a z bazy jest pobrana tylko pierwsza napotkana. Co robię źle? Czy błąd jest w pętli WHILE czy co? Proszę o pomoc.

[nospor]

nie:('$comma_separated')
a: ($comma_separated)

czemu wy zawsze bez namyslu rzucacie tymi ciapkami na lewo i prawo?

[apkc]

Już próbowałem!
Po tej zmianie zwraca mi ostatni rekord.

[nospor]

$ph=$wiersz['ph'];

no bo zakazdym obrotem petli nadpisujesz zmienną $ph (IMG:style_emoticons/default/smile.gif)

[kchrapa]

Witam!

Problem jest w implode oraz w zapytaniu:

1. Kiedy polaczyles implode'em tablice podales jako separator przecinek, czyli wynik:

1,2,3,4

i niby ok.

2. Ale w zapytaniu podstawiles zmienna, obejmujac ja ciapkami:
('$v_zmienna')

Czyli zapytanie przyjelo postac:

SELECT ... FROM .... WHERE `kj` IN ('1,2,3,4')

a wiec zamiast podac po przecinku kolejna wartosc dla IN'a , podales jeden string zawierajacy liczby po przecinku.

Jako ze MySQL jest mocno liberalny, obcial sobie pierwsza wartosc z listy (jedynke) i z niej skorzystal
(taki jego sposob na konwersje do liczby ;-)). Wiec dostales pierwszy wiersz z listy zamiast wszystkie cztery.

Inny system DB - np. Postgres krzyknal by Ci blad, ze podales napis tam gdzie sie spodziewa liczby (kolumna kj to integer) -i bylo by jasne - a mysql czasami przeholowuje z user friendly - ale to juz inna para kaloszy ;-)).

Rozwiazanie:

$comma_separated = implode("','", $chks);

- zwroc uwage na apostrofy przed i po przecinku. Czyli zapytanie przyjmie postac:

SELECT ... FROM .... WHERE `kj` IN ('1','2','3','4')

- i powinno byc ok ;-)

Podrawiam serdecznie,
Kacper

============================================
Szkolenia PHP, Warszawa

http://www.AplikacjeInternetowe.pl

[apkc]

Dzięki kchrapa. Po wstawieniu

[PHP] pobierz, plaintext 
$comma_separated = implode("','", $chks);
[PHP] pobierz, plaintext 

Daje mi coś taiego

[PHP] pobierz, plaintext 
SELECT ... FROM .... WHERE `kj` IN (1','2','3','4)
[PHP] pobierz, plaintext 

Więc jeszcze coś nie tak.

[nospor]

przeciez kchrapa napisal ci dokladnie to samo z tą roznicą, ze on mysli ze kod musi wygladac tak:
IN ('1','2','3','4')
a w cale nie musi tak wygladac. wystarczy ze bedzie tak:
IN (1,2,3,4)
czyli dokladnie to co ja ci napisalem. Na dodatek podal ci zly kod do generowanie swojego zamyslu...

[apkc]

przeciez kchrapa napisal ci dokladnie to samo z tą roznicą, ze on mysli ze kod musi wygladac tak:
IN ('1','2','3','4')
a w cale nie musi tak wygladac. wystarczy ze bedzie tak:
IN (1,2,3,4)
czyli dokladnie to co ja ci napisalem. Na dodatek podal ci zly kod do generowanie swojego zamyslu...

Ok dzięki. Zczytuje mi wszystkie dane.

Ten post edytował apkc 2.02.2010, 22:26:03

[kchrapa]

Witam!

Nospor:

Ehh,oczywiscie,ze nie musi byc w ciapkach (mam na mysli skladnie sql).Nie wiem skad pomysl, ze uwazam ze musi ...

Te ciapki nie sa z nadmiaru sily w palcach - tylko z przyzwyczajenia. Zabezpieczenie przed sql injection jesli nie korzystamy
z prepare/execute wymaga ich - oczywiscie w polaczeniu z mysql_real_escape_string/addslashes.
Mozna byloby zrezygnowac z tego i uzyc regexp'a wpuszczajacego tylko liczby calkowite - ale osobiscie wole to
ze soba polaczyc.

Wiec mysle, ze i ty rzucasz nimi (ciapkami) na lewo i prawo - chyba zgodzisz sie ze mna ;-)


Hmm - a tak z ciekawosci - w ktorym miejscu podalem zly kod? Patrze , patrze - i zdaje sie ze masz lepszy wzrok ode mnie...

Pozdrawiam serdecznie,
Kacper


============================================
Szkolenia PHP, Warszawa

http://www.AplikacjeInternetowe.pl

[nospor]

Wiec mysle, ze i ty rzucasz nimi (ciapkami) na lewo i prawo - chyba zgodzisz sie ze mna ;-)

cos jest liczba, wiec nie daje tego w ciapki a ty do mnie tekstem ze ja ciapkami rzucam? Co piles? (IMG:style_emoticons/default/winksmiley.jpg)

Hmm - a tak z ciekawosci - w ktorym miejscu podalem zly kod? Patrze , patrze - i zdaje sie ze masz lepszy wzrok ode mnie...

No twoj kod wygenerowal:
IN (1','2','3','4)
nadal uwazasz ze to jest wlasciwy kod? Nie zapomniales o czyms?

[kchrapa]

Nie zapomnialem ;-)

Kod apkc oryginalnie wygladal tak ( post z 21:38 ):


$zapytanie = "SELECT `ph` FROM `analizys` WHERE `kj` IN ('$comma_separated')";

czyli zmienna $comma_separated byla objeta apostrofami.

Dla tej linijki podalem nowa wersja implode ;-)

Choc oczywiscie, mozna bylo obciac tez ciapki przy zmiennej, i jego poprzedni implode bez ciapkow by zadzialal - tak jak Ty napisales.

Zdaje sie, ze nasz kolega z rozpedu (pozno juz bylo ;-)) , zastosowal obie rady (moja i Twoja) - dodal apostrofy w implode
i obcial w stringu ;-) I odwrocil sytuacje ;-)Ale, moze sie myle - tutaj apkc musialby sie wypowiedziec ;-)

>> cos jest liczba, wiec nie daje tego w ciapki a ty do mnie tekstem ze ja ciapkami rzucam? Co piles? winksmiley.jpg
Nie w tym konkretnym wypadku. Mialem na mysli ogolnie komunikacje z baza ;-) A pilem... heh, herbate jak na razie ;-)

Pozdrawiam serdecznie,
Kacper


============================================
Szkolenia PHP, Warszawa

http://www.AplikacjeInternetowe.pl

[nospor]

Nie zapomnialem ;-)

Kod apkc oryginalnie wygladal tak ( post z 21:38 ):


$zapytanie = "SELECT `ph` FROM `analizys` WHERE `kj` IN ('$comma_separated')";

czyli zmienna $comma_separated byla objeta apostrofami.

Dla tej linijki podalem nowa wersja implode ;-)

Choc oczywiscie, mozna bylo obciac tez ciapki przy zmiennej, i jego poprzedni implode bez ciapkow by zadzialal - tak jak Ty napisales.

Zdaje sie, ze nasz kolega z rozpedu (pozno juz bylo ;-)) , zastosowal obie rady (moja i Twoja) - dodal apostrofy w implode
i obcial w stringu ;-) I odwrocil sytuacje ;-)Ale, moze sie myle - tutaj apkc musialby sie wypowiedziec ;-)

Widze ze nadal nie wiesz gdzie zrobiles blad. Dobrze, wytlumacze ci to, bo widze ze robisz szkolenia wiec lepiej bys ludziom na szkoleniach tych bledow nie przekazał.
Twoj sposob:

[PHP] pobierz, plaintext 
$chks = array(1,2,3,4);
$comma_separated = implode("','", $chks);
echo $comma_separated;
[PHP] pobierz, plaintext 

Daje tekst: 1','2','3','4
brakuje apostrofa na początku i na koncu. Nalezy wiec twoj kod poprawic:

[PHP] pobierz, plaintext 
$chks = array(1,2,3,4);
$comma_separated = "'".implode("','", $chks)."'";
echo $comma_separated;
[PHP] pobierz, plaintext 

by uzyskac wlasciwy ciag: '1','2','3','4'

>> cos jest liczba, wiec nie daje tego w ciapki a ty do mnie tekstem ze ja ciapkami rzucam? Co piles? winksmiley.jpg
Nie w tym konkretnym wypadku. Mialem na mysli ogolnie komunikacje z baza ;-)

To ze ty tak robisz, nie znaczy ze inni tak robią. Gdy ja wkladam do bazy liczbe 5 to wkladam do bazy liczbe 5 a nie tekst '5'.

[kchrapa]

Nospor:

Czy przeczytales moj ostatni post ze zrozumieniem ?

>Kod apkc oryginalnie wygladal tak ( post z 21:38 ):
>$zapytanie = "SELECT `ph` FROM `analizys` WHERE `kj` IN ('$comma_separated')";
>czyli zmienna $comma_separated byla objeta apostrofami.
> Dla tej linijki podalem nowa wersja implode ;-)


Oczywiscie, ze jesli wykonasz po prostu echo na zmiennej to dostaniesz bez ciapkow zewnetrznych.
Ale apkc uzyl jej w konkretnym kontekscie - w zapytaniu SQL, gdzie zmienna BYLA OBJETA APOSTROFAMI !

Dla tego kontekstu podalem kod. I dlatego nie ma w nim bledu - bo apkc umiescil te apostrofy !
A pozniej - jak przypuszczam WYCIAL JE za Twoja rada ! Czytaj dokladnie, zanim zaczniesz krytykowac.


>To ze ty tak robisz, nie znaczy ze inni tak robią. Gdy ja wkladam do bazy liczbe 5 to wkladam do bazy liczbe 5 a nie >tekst '5'.

Proponuje abys zapoznal sie z dokumentacja php nt. danych wejsciowych - ktore sa stringiem , mimo
ze jest to liczba "z wygladu" - krotkie info jest chocby przy is_int() - http://php.net/manual/en/function.is-int.php .
Jesli dane pochodza z pliku - takze beda stringiem. Mozna je przepuszczac przez intval() , ale tez nie jest to
idealne rozwiazanie.

Nie sadze, aby apkc liste id mial wpisana z palca w skrypcie - jest to malo prawdpodobne, raczej pobieral je
z jakiegos wejscia - i jesli nie bylo to np. z bazy - to byly to stringi.

Poza tym , ufanie ze dane wejsciowe zawieraja liczby (czyli sa calkowicie bezpieczne), bo ty tak chcesz , jest naiwne i wprowadza dosc powazne zagrozenia. Wiec zanim bedziesz ludzi krytykowac za restrykcyjne walidowanie danych - zastanow sie glebiej. To ze Ty podchodzisz "lajtowo" do tematu , nie oznacza ze inni tak robia...





Pozdrawiam ,
Kacper

[nospor]

Oczywiscie, ze jesli wykonasz po prostu echo na zmiennej to dostaniesz bez ciapkow zewnetrznych.
Ale apkc uzyl jej w konkretnym kontekscie - w zapytaniu SQL, gdzie zmienna BYLA OBJETA APOSTROFAMI !

Tak, moj blad,przepraszam.

>To ze ty tak robisz, nie znaczy ze inni tak robią. Gdy ja wkladam do bazy liczbe 5 to wkladam do bazy liczbe 5 a nie >tekst '5'.

Proponuje abys zapoznal sie z dokumentacja php nt. danych wejsciowych - ktore sa stringiem , mimo
ze jest to liczba "z wygladu" - krotkie info jest chocby przy is_int() - http://php.net/manual/en/function.is-int.php .
Jesli dane pochodza z pliku - takze beda stringiem. Mozna je przepuszczac przez intval() , ale tez nie jest to
idealne rozwiazanie.

Nie sadze, aby apkc liste id mial wpisana z palca w skrypcie - jest to malo prawdpodobne, raczej pobieral je
z jakiegos wejscia - i jesli nie bylo to np. z bazy - to byly to stringi.

Poza tym , ufanie ze dane wejsciowe zawieraja liczby (czyli sa calkowicie bezpieczne), bo ty tak chcesz , jest naiwne i wprowadza dosc powazne zagrozenia. Wiec zanim bedziesz ludzi krytykowac za restrykcyjne walidowanie danych - zastanow sie glebiej. To ze Ty podchodzisz "lajtowo" do tematu , nie oznacza ze inni tak robia...

No ale w ktorym miejscu ja napisalem, ze dane wkladam do zapytania jak leci? Jesli to ma byc liczba, to albo ją waliduje albo rzutuje na liczbe i do zapytania wkladam liczbe a nie 'tekst'.

Chodzi o to, ze dobrze do zapytania jak cos jest liczbą to nalezy to wkladac jako liczbe a nie jako tekst. To uczy dobrych nawyków na później

Wiec zanim bedziesz ludzi krytykowac za restrykcyjne walidowanie danych - zastanow sie glebiej. To ze Ty podchodzisz "lajtowo" do tematu , nie oznacza ze inni tak robia...

A gdzie jak cie krytykowalem za walidacje danych? Ja cie krytykowalem za wkladanie liczb jako tekst (IMG:style_emoticons/default/smile.gif)

Te ciapki nie sa z nadmiaru sily w palcach - tylko z przyzwyczajenia. Zabezpieczenie przed sql injection jesli nie korzystamy
z prepare/execute wymaga ich - oczywiscie w polaczeniu z mysql_real_escape_string/addslashes.

Conajmniej dziwne podejscie przepusczac liczbe przez mysql_escape_string. Liczb to liczba, zrzutuj na liczbe i nie bawisz sie w zadne escapowanie.

[apkc]

Panowie powoli!
Ja potrzebowałem pomocy, bo jestem zielony w te "klocki". Odpisaliście prawie jedocześnie na ten post więc już wogóle zgłupiałem i prawda prawdą, (chyba mniej świadomie) ale połączyłem wasze sugestie w jedną i dlatego wyszły mi takie bzdury. Jeszcze raz dziękuję Wam obu za pomoc.

[kchrapa]

>No ale w ktorym miejscu ja napisalem, ze dane wkladam do zapytania jak leci?

Masz racje - zbyt daleko idace przypuszczenie wysunalem ;-) Przepraszam.

> Jesli to ma byc liczba, to albo ją waliduje >albo rzutuje na liczbe i do zapytania wkladam liczbe a nie 'tekst'.
>A gdzie jak cie krytykowalem za walidacje danych? Ja cie krytykowalem za wkladanie liczb jako tekst

Z punktu widzenia DB nie ma to znaczenia - i tak serwer automatycznie dokona konwersji do typu danych kolumny.
Jesli mu sie nie uda - wyrzuci blad. Ale podkreslam ,ze i tak do tego nie dojdzie, bo na poziomie PHP nastapi
restrykcyjna walidacja (przy moim podejsciu) i zapytanie w ogole nie zostanie wyslane ;-)

Nie chce kruszyc kopii - obaj mamy po prostu troche rozne podejscia. Ja potencjalne liczby waliduje regexpem ,Ty
je rzutujesz.
I jak sadze - pewnie tez walidujesz - bo konwersja moze sie nie powiesc i funkcja (np. intval() lub inna) , moze zwrocic logiczny falsz - i w koncu po skonwertowaniu do int'a przez serwer DB wstawi sie wiersz z wartoscia 0 ;-) .

Masz - skadinad dobre - nawyki z innych jezykow ,ale to powoduje dwukrotna robote w tym kontekscie ;-) Nie oceniam, po prostu masz inne podejscie. Ja generalnie konwertuje tam, gdzie jest to niezbedne - jak np. w JS.

Pozdrawiam i dzieki wielkie za intensywna dyskusje ;-)
Kacper







>Conajmniej dziwne podejscie przepusczac liczbe przez mysql_escape_string. Liczb to liczba, zrzutuj na liczbe i nie bawisz >sie w zadne escapowanie.

[nospor]

,ale to powoduje dwukrotna robote w tym kontekscie

No dobra, to teraz już na spokojnie:
napisz, jesli mozesz w ktorym miejscu ja robie podwójną robote a ty nie. Proszę na przykładach, by znowu nie było nieporozumień (IMG:style_emoticons/default/winksmiley.jpg)

Panowie powoli!
Ja potrzebowałem pomocy, bo jestem zielony w te "klocki". Odpisaliście prawie jedocześnie na ten post więc już wogóle zgłupiałem i prawda prawdą, (chyba mniej świadomie) ale połączyłem wasze sugestie w jedną i dlatego wyszły mi takie bzdury. Jeszcze raz dziękuję Wam obu za pomoc.

Ależ proszę bardzo. Oboje sie cieszymy ze pomogliśmy, a teraz wyjasniamy jeszcze tylko kwestie sporne, które i tobie mogą sie przydac na przyszlosc (IMG:style_emoticons/default/smile.gif)

I jak sadze - pewnie tez walidujesz - bo konwersja moze sie nie powiesc i funkcja (np. intval() lub inna) , moze zwrocic logiczny falsz

no nie moze. co najwyzej zwroci 0, gdy przepuszcze np. taki ciag "blabla". W niczym mi to nie przeszkadza. Oczekiwałem liczby i dostałem liczbe.

Z punktu widzenia DB nie ma to znaczenia - i tak serwer automatycznie dokona konwersji do typu danych kolumny.

No wlasnie, ale z punktu widzenia DB MySQL. A jak sie przesiądzie na inną:

Inny system DB - np. Postgres krzyknal by Ci blad, ze podales napis tam gdzie sie spodziewa liczby (kolumna kj to integer) -i bylo by jasne - a mysql czasami przeholowuje z user friendly - ale to juz inna para kaloszy ;-)).

to bedzie ból bo nabrał złych nawyków, które ty propagujesz. (IMG:style_emoticons/default/smile.gif)

[kchrapa]

Moze nie podwojna - przesadzilem ;-) Ale dodatkowa czasami :-)

Wersja 1 - tylko walidacja.
<?php

// Walidacja
//tylko liczby calkowite
if (preg_match('/[^0-9]/',$_GET['ilosc'])){
echo 'Bledna ilosc';
exit();
}

//j.w.
if (preg_match('/[^0-9]/',$_GET['id_produktu'])){
echo 'Bledne id produktu';
exit();
}

//ciapki z przyzwyczajenia ;-)
$v_sql="UPDATE produkty SET ilosc='{$_GET['ilosc']}' WHERE id_produktu='{$_GET['id_produktu']}'";
$o_db->Execute($v_sql);


?>

w efekcie,jesli user poda cos co nie jest liczba calkowita (np . ilosc - 'xyz@cos', to program przerwie sie na etapie walidacji.
I ilosc produktu nie zostanie zmieniona.

Jesli jednak bysmy poprzestali np. na intval , bez walidacji,to moglibysmy zaktualizowac blednie dane:

Wersja 2 - samo intval
<?php

//nasza bledna dana (zyz@cos) zamieni sie na 0 - co przestawi ilosc produktu na zero
$_GET['ilosc']=intval($_GET['ilosc']);
$_GET['id_produktu']=intval($_GET['id_produktu']);

$v_sql="UPDATE produkty SET ilosc={$_GET['ilosc']} WHERE id_produktu={$_GET['id_produktu']}";
$o_db->Execute($v_sql);

?>

Wiec zeby uniknac powyzszego problemu, pewnie przed intval dodajesz podobna walidacje - czyli mamy i walidacje i konwersje ;-)
W sumie to nie tak duzo wiecej - a pewnie u ciebie rzutowanie jest we krwi jak u mnie ciapki ;-)wiec generalnie zaden problem
jak sie dobrze przyjrzec ;-)

Mysle - ze w tym przypadku i ciapki(u mnie) i intval( u ciebie) sa zbedne - ale co sila przyzwyczajenia to sila przyzwyczajenia ;-) :-)


Pozdrawiam,
Kacper

[nospor]

//nasza bledna dana (zyz@cos) zamieni sie na 0 - co przestawi ilosc produktu na zero

Widzisz, twoja walidacja sprawdza czy jest liczbą. Jak ktoś poda 0 to Twoja walidacja to przepusci i w efekcie dostaniesz 0 tak jak i ja robiac rzutowanie na tekscie. Widzisz jakąś roznice w efekcie koncowym?

Wiec zeby uniknac powyzszego problemu, pewnie przed intval dodajesz podobna walidacje - czyli mamy i walidacje i konwersje

Nie, nie robie walidacji. Ma byc liczbą wiec rzutuje na liczbe i po sprawie. Walidacja jest tylko wowczas, jesli liczba nie moze byc zerem albo liczbą spoza jakiegoś zakresu. Ale to i przy Twojej metodzie musialbym też dodac tę dodatkową walidacje, wiec nadal nie ma zadnego dodatkowego narzutu.

Mysle - ze w tym przypadku i ciapki(u mnie) i intval( u ciebie) sa zbedne

Niestety nadal uwazam ze rzutowanie na liczbe jest ok a dawanie ciapkow jest złym nawykiem. (IMG:style_emoticons/default/smile.gif)

[kchrapa]

Witaj nospor!

Wybacz za pozna odpowiedz, ale ostatnio mialem sporo pracy i nie mialem czasu odpowiedziec.

Kontynuujac bardzo ciekawa dyskusje :-)....



I. Cytat z wczesniejszego posta, w ktorym mnie zacytowales:-)

kchrapa :
Z punktu widzenia DB nie ma to znaczenia - i tak serwer automatycznie
dokona konwersji do typu danych kolumny.

nospor :
No wlasnie, ale z punktu widzenia DB MySQL. A jak sie przesiądzie na inną:

kchrapa:
Inny system DB - np. Postgres krzyknal by Ci blad, ze podales napis tam gdzie sie
spodziewa liczby (kolumna kj to integer) -i bylo by jasne - a mysql czasami przeholowuje
z user friendly - ale to juz inna para kaloszy ;-)).

nospor:
to bedzie ból bo nabrał złych nawyków, które ty propagujesz.

Chcialbym zauwazyc, ze te dwie moje wypowiedzi dotycza innych aspektow - polaczyles je w
jedno, wyrywajac z kontekstu.

I. Pierwsza wypowiedz ("Z punktu widzenia DB..")- chodzilo o automatyczne rzutowanie
POPRAWNYCH FORMALNIE LICZB (calkowitych i rzeczywistych) przez RDBMS. Jesli poprawna liczba
bedzie w ciapkach, zaden z systemow : MySQL, PostgreSQL, Oracle, MS SQL Server czy Firebird
nie bedzie mial najmniejszych problemow. Automatycznie dokona rzutowania i nawet sie
nie zajaknie(nie jestem pewien jak z DB2 - pracowalem w nim ostatnio z 10 lat temu...i nie pamietam,
ale pewnie podobnie).

Wiec nic nie zaboli przy przejsciu aplikacji na inny rdbms... ;-)
(a jesli sie pojawi problem - bedzie to jedynie kwestia zmiany w domyslnej konfiguracji).

II. Druga wypowiedz - wstawiles ja zeby potwierdzic ostatnie Twoje zdanie moimi slowami
("to bedzie bol..") - ale ona dotyczyla innego aspektu ;-)
Tutaj chodzilo mi o sytuacje , kiedy na wejscie trafia NIEPOPRAWNA LICZBA CALKOWITA
(np. podano liczbe z czescia dziesiatna).

MySQL domyslnie wykonuje liberalna konwersje, tracac czesc informacji (ucina po
przecinku/zaokragla), dosc liberalnie w przypadku klauzuli IN zachowuje sie tez Firebird i
Oracle.
Z kolei Postgres (wraz z MS SQL Server) , jesli bedzie w ciapkach - wyrzuci blad,
jesli bez ciapkow - przemilczy sprawe dokonujac specyficznej konwersji . Czyli raczej ciapki
wplywaja pozytywnie na zachowanie systemu, jako ze wywoluja blad nie pozwalajac
serwerowi wyrzucic nieadekwatnych danych.
Oczywiscie, powyzsze zachowanie podaje dla domyslnych ustawien tych rdbms'ow.

Reasumujac - w kontekscie zapytan SQL (bo tylko o tym byla mowa) - ujecie ich w ciapki wg
mojej wiedzy nie przynosi zadnych negatywnych konsekwencji,a biorac pod uwage
postgresa i mssqlserv - wrecz przeciwnie.

Aczkolwiek - jesli sa jakies obiektywne przyczyny (nie liczac przyzwyczajenia/gustu mojego
czy Twojego), o ktorych nie wiem a z powodu ktorych nalezy z ciapkow w SQL zrezygnowac -
bede wdzieczny za informacje :-)


Ustosunkuje sie jeszcze do ostatniej Twojej wypowiedzi :

Nospor:

Kacper:
//nasza bledna dana (zyz@cos) zamieni sie na 0 - co przestawi ilosc produktu na zero

Nospor:
Widzisz, twoja walidacja sprawdza czy jest liczbą. Jak ktoś poda 0 to Twoja walidacja to
przepusci i w efekcie dostaniesz 0 tak jak i ja robiac rzutowanie na tekscie. Widzisz jakąś
roznice w efekcie koncowym?

Kacper:
Wiec zeby uniknac powyzszego problemu, pewnie przed intval dodajesz podobna walidacje -
czyli mamy i walidacje i konwersje

Nospor:
Nie, nie robie walidacji. Ma byc liczbą wiec rzutuje na liczbe i po sprawie. Walidacja jest
tylko wowczas, jesli liczba nie moze byc zerem albo liczbą spoza jakiegoś zakresu. Ale to i
przy Twojej metodzie musialbym też dodac tę dodatkową walidacje, wiec nadal nie ma zadnego
dodatkowego narzutu.

Kacper:
Mysle - ze w tym przypadku i ciapki(u mnie) i intval( u ciebie) sa zbedne

Nospor:
Niestety nadal uwazam ze rzutowanie na liczbe jest ok a dawanie ciapkow jest złym nawykiem.

I tutaj musze Ci jednak zwrocic uwage ,ze rzutowanie bez walidacji nie jest optymalnym podejsciem i moze
spowodowac konkretne problemy. Dlaczego?

To prawda, jesli uzytkownik przy zmianie ilosci produktu wpisze zero, i moj i Twoj program
to przepusci... bo oczywiscie zerowy stan produktow jest jak najbardziej sensowny.I moim
celem nie bylo uniemozliwienie ustawienia takiej wartosci.

Stosowanie walidacji w tym przypadku jest w innym celu - przechwycenie sytuacji,jesli user
nieswiadomie poda cos,co nie jest poprawna liczba calkowita w systemie dziesietnym (a nie
znam chyba usera, ktory SWIADOMIE bedzie probowal wpisac w tym miejscu zapis szesnastkowy
lub binarny - pomijam proby atakow).

I zwroc uwage na dwa podejscia do problemu :

A. z walidacja - system odrzuci jego żądanie informujac o bledzie.Czyli user od razu dowie
sie ze jest problem i swiadomie go skoryguje.

Sedno dzialania: Walidacja nie dopusci do przeklamania danych.

Potrzebna jest tu takze walidacja, aby system RDBMS tez nie dokonal niepoprawnego
rzutowania (np. zaokraglajac liczbe zmiennoprzecinkowa).


B. bez walidacji, ale z rzutowaniem - system skonwertuje bledna dana do 0
i zaktualizuje/wstawi produkt z niepoprawna iloscia.Bez jakiejkolwiek noty dla usera.
Dla jakich danych to nastapi ? Np.:
- 0x1B
- ania'
- x3444

Zarowno intval() jak i rzutowanie (int) liczba , zmodyfikuje bledne dane - zamiast
odrzucic, zmieni "cichaczem" na zero.

Pol biedy, jesli to robi user dla pojedynczego rekordu (moze zauwazy blad) -ale jesli importuje z csv
kilkaset tysiecy rekordow,program sie nawet nie zajaknie - a doswiadczenie pokazuje,
ze w duzej czesci systemow mamy smieci ( widzialem systemy (zarowno male, jak i miedzynarodowych korporacji) gdzie w polu numer_domu bylo wpisane "zosia" )) - podobnie w plikach csv od userow czy innych zrodlach danych.

Reasumujac - na tym poziomie widac bardzo istotna roznice w efekcie koncowym miedzy naszymi
rozwiazaniami.

Walidacja jest niezbedna nie tylko wtedy, gdy nie chcesz wpuscic zera itp, bo
jesli user wpisze 'gucio' , do bazy trafia calkowicie bledne dane (choc poprawne skladniowo
z uwagi na rzutowanie).

Mysle wiec, ze powinienes jednak rozwazyc wprowadzenie walidacji tam, gdzie
robisz tylko rzutowanie.Uszczelni ona system sprawiajac,ze bedzie mniej podatny na
umieszczanie w nim nieadekwatnych informacji.


Pozdrawiam serdecznie ,
Kacper

[nospor]

Ale mnie nie lubisz ze zmuszasz mnie do przeczytania takiej ilości tekstu... (IMG:style_emoticons/default/winksmiley.jpg)
Ustosunkuję się tylko do końcówki bo już po tak długiej przerwie odeszła mi ochota na tę zaciętą "kłótnie" (IMG:style_emoticons/default/smile.gif) . Mam nadzieję ze za bardzi się nie pogniewasz z tego powodu.

Walidacja jest niezbedna nie tylko wtedy, gdy nie chcesz wpuscic zera itp, bo
jesli user wpisze 'gucio' , do bazy trafia calkowicie bledne dane (choc poprawne skladniowo
z uwagi na rzutowanie).

Mysle wiec, ze powinienes jednak rozwazyc wprowadzenie walidacji tam, gdzie
robisz tylko rzutowanie.Uszczelni ona system sprawiajac,ze bedzie mniej podatny na
umieszczanie w nim nieadekwatnych informacji.

Problem w naszej dyskusji polega na tym, ze mówimy ogólnie albo w ramach sytuacji o której sami myślimy.
Ja mówiąc o rzutowaniu bez walidacji miałem na myśli sytuację, gdy user nie wprowadza danych tylko ma je podane i musi coś zaznaczyć. (oczywiście wybiegłem raz do wpisania tekstu, by pokazac ci prostą walidacje vs rzutowanie i wpadka z zerem).
W tym temacie user zaznaczał checkboxy, on nic nie wpisywał. Zeby wiec wartosci checkboxów były złe, to user by musiał specjalnie grzebac w zródle strony by je podmienic i przeslac na serwer inne wartosci niz oczekiwalismy. I tutaj zwykle rzutowanie na liczbe jest wystarczające.
No chyba ze musimy sprawdzic czy wartosci są z danego zakresu, ale wówczas i ty i ja musismy dorobic dodatkową walidacje.

W przypadku gdy user wpisuje dane to i ja również robię walidacje jesli jest to niezbędne (IMG:style_emoticons/default/smile.gif) W tym przypadku zwyklych checkboxów walidacja nie była niezbędna - wystarczylo zwykle rzutowanie.

edit:
przeczytalem jeszcze raz twoj post i jednak odpowiem na jeszcze jedno

I. Pierwsza wypowiedz ("Z punktu widzenia DB..")- chodzilo o automatyczne rzutowanie
POPRAWNYCH FORMALNIE LICZB (calkowitych i rzeczywistych) przez RDBMS. Jesli poprawna liczba
bedzie w ciapkach, zaden z systemow : MySQL, PostgreSQL, Oracle, MS SQL Server czy Firebird
nie bedzie mial najmniejszych problemow. Automatycznie dokona rzutowania i nawet sie
nie zajaknie(nie jestem pewien jak z DB2 - pracowalem w nim ostatnio z 10 lat temu...i nie pamietam,
ale pewnie podobnie).

Wiec nic nie zaboli przy przejsciu aplikacji na inny rdbms... ;-)
(a jesli sie pojawi problem - bedzie to jedynie kwestia zmiany w domyslnej konfiguracji).

Slyszałem, ze postgre wywala sie gdy dla pola liczbowego uzyjemy ciapków. Nawet jesli mozna to zmienic w konfiguracji to miej na uwadze, ze nie kazdy ma mozliwosc zmiany konfiguracji bazy danych. WIec lepiej jak cos ma byc liczbą to niech sie to traktuje jako liczbe a nie jako tekst.

[kchrapa]

Ale mnie nie lubisz ze zmuszasz mnie do przeczytania takiej ilości tekstu... winksmiley.jpg

Nie jest tak zle ;-)

Ustosunkuję się tylko do końcówki bo już po tak długiej przerwie odeszła mi ochota na tę zaciętą "kłótnie" smile.gif. Mam nadzieję ze za bardzi się nie pogniewasz z tego powodu.

Ja tez powoli trace "werwe" ;-) Aczkolwiek, konstruktywna ta "klotnia" i chyba widac konsensus na horyzoncie :-)

Problem w naszej dyskusji polega na tym, ze mówimy ogólnie albo w ramach sytuacji o której sami myślimy.
Ja mówiąc o rzutowaniu bez walidacji miałem na myśli sytuację, gdy user nie wprowadza danych tylko ma je podane i musi coś zaznaczyć. (oczywiście wybiegłem raz do wpisania tekstu, by pokazac ci prostą walidacje vs rzutowanie i wpadka z zerem).
W tym temacie user zaznaczał checkboxy, on nic nie wpisywał. Zeby wiec wartosci checkboxów były złe, to user by musiał specjalnie grzebac w zródle strony by je podmienic i przeslac na serwer inne wartosci niz oczekiwalismy. I tutaj zwykle rzutowanie na liczbe jest wystarczające.
No chyba ze musimy sprawdzic czy wartosci są z danego zakresu, ale wówczas i ty i ja musismy dorobic dodatkową walidacje.

W przypadku gdy user wpisuje dane to i ja również robię walidacje jesli jest to niezbędne smile.gif W tym przypadku zwyklych checkboxów walidacja nie była niezbędna - wystarczylo zwykle rzutowanie.

W sumie - masz racje:-) Weszlismy w dosc glebokie niuanse, ktore maja znaczenie w konkretnych,
specyficznych sytuacjach - i problematyczne jest tego uogolnienie. A z kolei rozpatrywanie poszczegolnych przypadkow-
troche by zajelo i chyba rzeczywiscie szkoda na to czasu w tym kontekscie;-)

Slyszałem, ze postgre wywala sie gdy dla pola liczbowego uzyjemy ciapków. Nawet jesli mozna to zmienic w konfiguracji to miej na uwadze, ze nie kazdy ma mozliwosc zmiany konfiguracji bazy danych. WIec lepiej jak cos ma byc liczbą to niech sie to traktuje jako liczbe a nie jako tekst.

Domyslnie, dla poprawnych danych nie (np. dla 31 czy 22.14 ).Ale faktycznie,przypuszczam ze modyfikacja ustawien moze to zliberalizowac podobnie jak w innych systemach . Czasami mozna to sobie dopasowac samemu na poziomie sesji,czasami nie.

Jesli chodzi o dostep do konfiguracji serwera - masz racje, nie zawsze go mamy. Podalajac ta notke
w kontekscie calego watku - czyli przeniesienia z MySQL na inny system - mialem na uwadze to,ze gdy
przenosi sie aplikacje ze slabszego na mocniejszy rdbms jest zwykle ku temu istotny powod (wydajnosciowy lub
funkcjonalny) - i wtedy ten rdbms pracuje wylacznie dla naszej aplikacji - co pozwala zmienic dowolnie ustawienia.
(w kazdym razie - w moim wypadku zawsze tak bylo).

Ale , moze oczywiscie byc tez inaczej (np. gdy przenosimy aplikacje na wspolny,firmowy serwer oracla)... -i szkoda naszego czasu na rozpatrywanie tutaj kolejnych tysiecy opcji :-) :-)

W kazdym razie - dzieki za dyskusje :-)

Pozdrawiam serdecznie,
Kacper

[nospor]

Domyslnie, dla poprawnych danych nie (np. dla 31 czy 22.14 ).Ale faktycznie,przypuszczam ze modyfikacja ustawien moze to zliberalizowac podobnie jak w innych systemach . Czasami mozna to sobie dopasowac samemu na poziomie sesji,czasami nie.

Ostatnio jeden z uzytkowników "smiał powiedziec ze sie myle" ( (IMG:style_emoticons/default/winksmiley.jpg) ) nie zwracając uwagę na ciapki w zapytaniu dla liczby. Ja nie zwracalem na to uwagi w tamtym temacie bo akurat wtedy nie to było przyczyną problemów. Ale to był uzytkownik postgresa i dla niego dawanie ciapkow dla liczb konczylo sie errorem bazy. Nie bylo dla niego zrozumiałe ze mysql pozwala na takie kwiatki
http://forum.php.pl/index.php?showtopic=141771&hl=
Dlatego w tym temacie tak mocno akcentuję ze liczba to liczba a nie tekst, bo w przyszlosc z powodu złych nawyków mogą byc niepotrzebne problemy.

i chyba widac konsensus na horyzoncie

A potem zyli długo i szczęsliwie czego tobie i sobie życzę (IMG:style_emoticons/default/smile.gif)