Newsgroup: it.comp.www.php
Titolo: problema script php

Salve, nel mio database ho una tabella in cui vengono salvati gli iscritti
al mio sito; c'è un campo fascia_eta che vale 1 se l'iscritto ha da 16 a 25 
anni,
2 da 26 a 35 anni, 3 da 36 a 45 anni e 4 da 46 anni in su.
Sempre in quella tabella ho 3 campi (giorno, mese e anno di nascita 
dell'iscritto);
ora ho scritto uno script php in modo che aggiorni automaticamente il campo
fascia_eta usando un cron job (per esempio se un iscritto ha 25 anni e 
quindi fa parte della fascia 1,
quando finisce 26 anni diventa parte della fascia 2 e il campo fascia_eta 
deve aggiornarsi di conseguenza),
ma mi cambia tutti i record sempre con 4 con qualsiasi data di nascita.
Potete aiutarmi?
Questo è lo script:
<?php
// Collegamento ad database.
include("config.php");
$sql = "select * from form";
$res = mysql_query($sql) or die(mysql_error());
while($row=mysql_fetch_object($res))
{
    // Differenza in secondi tra la data corrente
    // e la mia data di nascita
    $differenza = time() - mktime(0, 0, 0, $row->mese_nascita, 
$row->giorno_nascita, $row->anno_nascita);
    // Calcolo età
    $eta = floor($differenza / 31536000);
    if(($eta >= 16) && ($eta <= 25))
        $fascia_eta = 1;
    elseif(($eta >= 26) && ($eta <= 35))
        $fascia_eta = 2;
    elseif(($eta >= 36) && ($eta <= 45))
        $fascia_eta = 3;
    else
        $fascia_eta = 4;
    $query = "UPDATE form SET fascia_eta = $fascia_eta";
    mysql_query($query) or die(mysql_error());
}
?> 

     $query = "UPDATE form SET fascia_eta = $fascia_eta";
manca la clausola WHERE
http://dev.mysql.com/doc/refman/5.0/en/update.html


evidentemente non soddisfa mai gli if.
Fai un bel var_dump di $differenza e $eta e vedi che numeri tira fuori.
A occhio io errori non ne vedo (a parte l'approssimazione che non tiene 
conto dei bisestili, ma penso lo consideri trascurabile).
-- 
Z.

Il 17/03/2011 17:51, Z. ha scritto:
vista ora la risposta di RedWiz, eh già, manca il where:P
evidentemente l'ultimo record aveva 4 :P
-- 
Z.

Ma perchè non fai 4 query con between?
Se hai le colonne separate, una roba del genere:
UPDATE form SET fascia_eta = 1 WHERE DATE_SUB(CONCAT(anno, mese,
giorno), NOW()) BETWEEN 16 AND 25
ho scritto alla buona, non ricordo esattamente la sintassi del
date_sub e probabilmente nel now() ci devi castare un date_format, ma
a rigor di logica con 4 query fai tutto.. volendo puoi anche fare una
sola query con un IF (per casi così semplici si può anche fare)

Riferimenti:
http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_date-sub
http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_date-format
http://dev.mysql.com/doc/refman/5.0/en/comparison-operators.html#operator_between
http://dev.mysql.com/doc/refman/5.0/en/if-statement.html


un db normalizzato non sempre è un db efficiente (anzi).
Certo in questo caso, vista la banalità dell'operazione concordo con te...
-- 
Z.

 un db normalizzato non sempre è un db efficiente (anzi).
Un DB non normalizzato è semplicemente ingestibile. Normalization is not
an option. Se avete problemi di performance, cambiate RDBMS.

"DaNieL"  ha scritto nel messaggio 
news:70908366-ce4d-4d5b...@u8g2000yqh.googlegroups.com...
Ma perchč non fai 4 query con between?



sola query con un IF (per casi cosě semplici si puň anche fare)
si infatti la soluzione era di usare 4 query con BETWEEN 16 AND 25, ecc. 


va bene se ti mando da Regione Lombardia a dirgli di triplicare il 
cluster di oracle perchè tu dici che un campo in + è brutto? :P
Se ce la fai , chiedigli pure di farci un contratto molto ricco (uso il 
plurale perchè a quel punto divido volentieri i soldi con te:D)
Se lavori su basi dati grosse non c'è alternativa, potrà essere poco 
elegante, probabilmente non andrei a insegnarlo a lezione a degli 
studenti (lo scoprono da soli quando lavorano poi :P), ma di fatto è così.
-- 
Z.

 studenti (lo scoprono da soli quando lavorano poi :P), ma di fatto è così.
No, non è così.
Io lavoro con basi dati dell'ordine delle centinaia di giga (sconfinando 
sempre più spesso nel terabyte) e gestire dei database "fatti a cazzo" 
(scusa il francesismo per dire "non normalizzati") significa perdere il 
triplo del tempo per capire da dove saltano fuori valori discrepanti o 
risultati imprevisti.
Andrebbe premesso che uso sempre meno RDBMS, preferisco alternative 
adatte a queste moli di dati (HDF5 e/o NoSQL) ma che hanno comunque le 
loro regole e forme di normalizzazione.
Ovviamente non "ce l'ho" con te :) Mi rompe solo le scatole vedere che 
quando lavoro con aziende estere hanno (quasi) sempre dei database 
esemplari, qui in Italia hanno (quasi) sempre dei minestroni 
ingestibili. E indovina chi si lamenta di performance, costi, tempi di 
manutenzione o implementazione...? ;-)

 manutenzione o implementazione...? ;-)
no, ci mancherebbe, però sottolineo che il db l'ha fatto una spa 
internazionale, non io:D
Ma alla luce dei vincoli che avevano io trovo abbiano agito nel modo 
migliore.
-- 
Z.

 anni,
[..]
Non scrivere inutilmente un dato che invecchia da solo.
Scrivi nel modo piů assoluto la data di nascita.
ciao, f.