MySQL atgriež nekorektus datu tipus(viss stringos)

[DarkSide]

Sveiki!

 

Sveiciens visiem šeit klātesošajiem, beidzot es ar esmu reģistrējies šai forumā un ļoti ceru uz Jūsu palīdzību ar padomu. Varbūt kādam iesācējam varēšu palīdzēt arī pats... Nu tad tā - te nu būs mana nepatīkamā problēma:

 

1) Vai esat ievērojuši, ka mysql_query (lietoju PHP4 nevis PHP5) atgriež visus MySQL datu tipus pārveidotus par string? Tikai NULL atgriež kā null. Kādas idejas kā šo procesu varētu labot, jo baigi besī pēc katra MySQL selekta pārveidot saņemtos datus (pareizāk sakot šo datu atribūtu tipus, lai varētu ar šiem atribūtiem veikt kādas normālas darbības - piemēram datumu pārbaude, integer saskaitīšana un citus aprēķinus).

 

2) HTML formās cik saprotu arī visur VALUE tiek izmantots tadu tips string. Atkal sanāk pārveidošana no integer->string, date->string utt...

 

3) No HTML formas saņemam (ar POST, GET) visus datu atribūtus atkal string formātā, kas atkal ir jāpārveido par integer, date utt., lai ar tiem veiktu sakarīgas darbības ar PHP.

 

4) Šos datus saglabājot MySQL šķiet sanāk atkal tos pārveidot par string...

 

Vienvārdsakot baigā sāpe ir veikt un galvenais kodēt visas šitās bezjēdzīgās pārveidošanas. Vai nav kāds veids (kāda komanda vai parametrs) ar ko varētu pateikt, ka ja lūk MySQL tabulā mums ir atribūts ar tipu int(8), tad arī PHP veicot komandu mysql_query saņem integer datu tipu, vai vēl būtiskāk ja MySQL datubāzē glabājas date lauks, tad PHP saņem date tipu (ops - tāds laikam nav PHP...)

 

Vispār pastāstiet savu pieredzi šai jautājumā!

 

P.S. Principā runa ir par ne maziņas PHP, MySQL datubāzu sistēmas izveidi. Tipa pasūtījumu uzskaite utt... Samērā nopietns projekts ar daudzām tabulām un attiecīgi daudziem skriptiem, kurus negribas pieblīvēt ar bezjēdzīgiem datu tipu pārveidojumiem (nemaz jau nerinājot par ātrdarbību).

[Aleksejs]

Nu nezinu... datu validācija, tak Tev jebkurā gadījumā jāveic. Validācijas laikā arī pie viena atrisināsi datu tipu problēmu!

[goldy]

PHP neprasa defineet variabljus tacu, ja $variable = 3 tad tas ir integers ,a naakamajaa rindinja $variable = 'tris' tad tas ir strings, kur ir probleema ko tu tur taisies defineet, tas nav pascal vai kas tamliidziigis kur vajag

var integer $variable = '3' (laikam taada bija sintakse)

Edited October 5, 2005 by goldy

[v3rb0]

vienīgais kas varbūt būs jāpārveido ir datumu formaati, no kaut kāda kas formās rādas - piem latviešu dd.mm.yyyy uz (iso? ) datumu yyyy-mm-dd. lai nebūtu problēmas ar nepareizi interpretētu datumu, bet ar ne vienmēr.

 

kā jau te saka, php variablu datu tipi netiek strikti defineeti - kaadu veertiibu pieskirsi mainigajam taada buus liidz izdomasi cita datu tipa veertibu pieskirt.

 

par to ka no mysql dabuu aaraa ciparus kaa stringus nepiekriitu - paarbaudi ar http://lv2.php.net/is_numeric ja netici.

[Grey_Wolf]

par datumiem piekriitu, bet no SQL var dabuut aaraa jau smuki noformeetu datuma stringu :)

 

 

par to ka no mysql dabuu aaraa ciparus kaa stringus nepiekriitu - paarbaudi ar http://lv2.php.net/is_numeric ja netici.

23998[/snapback]

 

par sho pameegjini shadu kodu un paskaties kas iznaaks

 

$result= mysql_query('SELECT * FROM `tabula`');
$row=mysql_fetch_array($result);
$a=gettype($row['id']);
echo $a;

[bubu]

Cits te saskata trūkumus, citi atkal priekšrocības - tāpēc jau php ir dinamiska valoda, ka nav atkarīga no saglabātajiem datu tipiem, bet konversijas notiek automātiski.

A tipus noteikti var dabūt no mysql (http://lv.php.net/manual/en/function.mysql-field-type.php) un tad ar php forcēti uzspiest to tipu: http://lv.php.net/manual/en/function.settype.php Bet jēga kāda?

Ja tev ir strings $str = "45"; tad taču tu tāpat vari operēt kā ar integeru: echo $str/5; Tur jau php priekšrocība no vienas puses!

[v3rb0]

es domaaju par datumu parveidosanas pirms dabusanas ieksaa datubaazee - piem datums 01.02.03 - einu sazini kaa datubaze sho sapratiis.

 

ar paarveidosanu ieksh datubazes pirms aaraa dabuusanas uzmaniigi - tur jaaskataas ka nesaanak paarveidot miljons datumus, lai gan vajag dabuut tikai 5cus smuki saformetus datumus.

[DarkSide]

$result= mysql_query('SELECT * FROM `tabula`');
$row=mysql_fetch_array($result);
$a=gettype($row['id']);
echo $a;

23999[/snapback]

 

string, ka es jums saku. Tikko vēlreiz pārliecinājos. Datubāzē man ir ID int(8) unsigned NOT NULL. Uzlaižu qveriju:

$result=mysql_query('SELECT id FROM tabula');
$row=mysql_fetch_object($result); /tas pats ar array arī/
echo 'ID='.$row->id.' TYPE='.gettype($row->id);

Rezultāts: ID=1 TYPE=string

 

P.S. Nu var jau būt ka tā ir priekšrocība (ir situācijas, kad tas patiesi ir forši), bet šai gadījumā man jau baigi gribētos būt 100% ka operēju ar pareiziem datu tipiem... lai gan, ja tā labi padomā - var jau uzlikt tam visam mīksto un operēt aar stringiem (cerot, ka konvertācijas pie katras operācijas notiks veiksmīgi automātiski, bet bišķi baidos uz to paļauties)...

 

P.P.S. Kādu datu tipu (MySQL) Jūs varētu ieteikt naudas summas saglabāšanai? Double? Numeric? Kā pēc savas pieredzes glabājas summu bez PVN, PVN, summu ar PVN? Vai ir ok darīt tā, ka glabājam datubāzē summu bez PVN un PVN summu un ja nepieciešams, tad formā varam veikt vienkāršu šo abu skaitļu saskaitīšanu un attēlot jau userim interesējošo summu ar PVN? Kāda ir Jūsu pieredze šai jautājumā?

[Kavacky]

Es gan neatceros, ka man kaut reizi kaut kas būtu saprasts ne tā.

[bubu]

Noteikti ne Double (peldošā punkta skaitļi taču nevar precīzi attēloties atmiņā, ja nav 2 pakāpes).

Numeric(m,n) jālieto.

[Roze]

Mysqlam ir CAST funkcija kuraa tu vari Castot kā integeru

 

http://dev.mysql.com/doc/mysql/en/charset-cast.html

http://dev.mysql.com/doc/mysql/en/cast-functions.html

 

tb SELECT CAST(id AS SIGNED) ..

vai vienkaarshaak SELECT id+0

 

Taču problēma jau nav MySQLā bet gan php ekstensijā jo tur izmantojot php lielisko iespēju visi variabļi anyway tiek pārveidoti par stringiem un ja tev nepieciešams konkrēts lauks ar konkrētu tipu jāizmanto

http://lv.php.net/settype vai vai (int)$row[lauks] vai $row[lauks]+0 (arī škiet)

 

Softiskās aplikācijās (izmantojot pa tiešo mysql / clienta api) visi dati tiek atgriezti tādos tipos kā definēti db lauki.

 

 

 

Par naudu runājot, pieredze rāda ka labāk ir glabāt mazākajā naudas vienībā veselus skaitļus (protams ja tas ir iespējams un nav jārēķina sīkāk) ja LVL tad tas būtu santīmos un izvadus jau tad dalīt ar 100.

[DarkSide]

Par naudu runājot, pieredze rāda ka labāk ir glabāt mazākajā naudas vienībā veselus skaitļus (protams ja tas ir iespējams un nav jārēķina sīkāk) ja LVL tad tas būtu santīmos un izvadus jau tad dalīt ar 100.

24012[/snapback]

Vot tā ir ideja kā māja! Nebija ienācis prātā! Ko citi saka par šādu pieeju? Izklausās baigi labi ne?

 

Par tiem stringiem būtu aptuveni skaidrs - cik saprotu, tad PHP anyway visus datu tipus pārveido un pārveidos par string un vēlāk jau viecot kautkādas darbības (piemēram, +0) pārveidos par integer, +0.0 pārveidos par double utt... Varbūt tas arī būtu ok, BET:

 

Neliels jautājums par MySQL sintaksi. Vai var rakstīt SELECT count(*) FROM tabula WHERE id="13"? Tobiš ja MySQL tabulās id ir int(8) vai ir obligāti jāraksta SELECT count(*) FROM table WHERE id=13 (bez ")?

[Kavacky]

"SELECT count(*) FROM `tabula` WHERE id='13'"

 

Visas vērtības, man šķiet, vienmēr ir jāraksta pēdiņās ( ' ' ).

[bubu]

Muļķības, skaitļus drīkst rakstīt nepēdiņās (un ` lietot arī ir muļķīgi, manā izpratnē):

SELECT count(*) FROM tabula WHERE id=13

[Roze]

Var likt var nelikt.

Oracle (vismaz 8) šķiet bija ķeska ar to ka piemēram '13' ir strings, bet bez pēdiņām ir integers līdz ar to netika izmantoti korekti indeksi ja tipi nesakrita.

 

Bet mysql query optimaizerim ir pofig. Vienīgais ja notiek juzerinputs (nevis hardcodec kverijs) tad '' gan vajadzētu likt jo var sanākt liela ziepe ja lietotājs ievadīs laukā ' un nevis ciparu :)