@Fabrizio23 said:
Ciao! Ho appena finito di leggere PHP ...
Un manuale di programmazione non è un romanzo, cosa significa ho letto? L'hai letto tutto d'un fiato, magari saltando le parti più difficili e complesse?
@Fabrizio23 said:
Mmmm cominciamo bene...ma non era scritto questo...:(
Ecco, appunto, come volevasi dimostrare.
@Fabrizio23 said:
Posso anche non metterlo però...ho letto uno script che non lo metteva...
Questo mi lascia basito e perplesso, non so se più basito o più perplesso.
Puoi fare anche così:
[PHP]
<select size="anno" name="anno">
<?php
for ($a = 1900; $a < 2011; $a++) {
if ($a != $anno) {
echo '<option VALUE="'.$a.'">'.$a.'</option>';
} else {
echo '<option VALUE="'.$a.'" selected>'.$a.'</option>';
}
}
?>
</select>
[/PHP]
Quello che ti accade è più che giustificato dal fatto che inserisci 2 volte il valore in questione, la prima come valore selezionato e la seconda come option. Per evitare ciò devi effettuare dei controlli. Riempire le option come fai tu è poco pratico, ti consiglio di effettuare un ciclo che automatizzi la cosa. Qualcosa del tipo:
[PHP]
<select size="anno" name="anno">
<option SELECTED VALUE="<?php echo $anno; ?>"><?php echo $anno;?></option>
<?php
for ($a = 1900; $a < 2011; $a++) {
if ($a != $anno) {
echo '<option VALUE="'.$a.'">'.$a.'</option>';
}
}
?>
</select>
[/PHP]
Sarebbe ancora meglio non cablare a codice il valore 2011 ed ottenerlo dinamicamente utilizzando qualche funzione PHP per le date.
Dal post identico che hai aperto tempo fa in un altro forum mi sembra di capire che dovresti studiare un po' di basi di programmazione web prima ancora che PHP, almeno per avere una minima cognizione di ciò che stai scrivendo.
Nel ciclo while modifichi la variabile $result per cui quando esso ripeterà il controllo troverà tutt'altro rispetto ai valori di partenza.
In alternativa a come stai facendo puoi utilizzare il tag form passando l'id_squadra come campo hidden.
O passi i dati che vuoi recuperare come parametri sull'URL al quale reindirizzi e poi li recuperi con $_GET[] oppure puoi inserire i dati di tuo interesse in sessione.
Forse perchè il manuale tentava di spiegare l'utilizzo delle funzioni?
@spatu said:
...
Entità: Libro,Autore,Curatore
Attributi: -Libro (romanzo,saggio,poesia,titolo,autore,curatore,ISBN (autenticatore),anno di edizione)
-Autore (cognome,nome,telefono,codice fiscale(identificatore)
-Curatore(cognome,nome,telefono,codice fiscale(identificatore)
...
Una prima modifica andrebbe effettuata all'entità Libro. Non è corretto inserire un attributo per ciascuna tipologia (se esse aumentassero oppure mutassero dovresti modificare l'entità). Sarebbe più corretto inserire un attributo tipologia ad una nuova entità Tipologia con una relazione 1:1, oppure inserire direttamente la tipologia di libro (Romanzo, Saggio o Poesia) all'interno di tale attibuto.
Inoltre la relazione esistente tra le entità Libro, Autore e Curatore è di n:m
per cui è necessaria l'introduzione di una terza entità che relazioni le entità Libro ed Autore e un'altra per relazionare le entità Libro e Curatore.
Ancora, le entità Autore e Curatore sono praticamente identiche inoltre (come da enunciato del problema) un autore può essere anche curatore e viceversa, per cui io non distinguerei tra Autori e Curatori, ma farei un unica entità (ad esempio Aut_Cur)
Quindi:
Libro (iban, titolo, tipologia, autore, curatore, anno), Aut_Cur (codfisc, nome, cognome, telefono) ed infine le due entità di relazione Aut_Lib (iban_libro, codfisc_aut_cur) e Cur_Lib (iban_libro, codfisc_aut_cur).
@dymissy said:
La differenza tra il punto 1 e il punto 2 è fondamentale.
Non so quanti di voi abbiamo studiato Basi di Dati ma, in pratica succede che nel primo diagramma E/R realizzato possono esserci delle relazioni non implementabili in SQL o difficilmente mantenibili e usabili (ad. esempio una relazione molti a molti tra due tabelle); proprio per questo si passa ad un raffinamento e ottimizzazione della tabella iniziale, quella richiesta nel punto 2.
Nello specifico se ad esempio nel primo caso hai fatto due tabelle:
-libri
-autori
è ovvio che a primo impatto viene una relazione molti a molti dato che più libri possono essere scritti da più autori e viceversa. Il punto 2 richiede proprio il raffinamento di queste relazioni; ad esempio se tra due tabelle c'è una relazione 1 ad 1 è buona norma inglobare le due tabelle in una soltanto, se c'è una relazione molti a molti è buona norma creare una terza tabella che servirà a "smistare" i dati in maniera da facilitare le query e cosi via.
Quanto dici è corretto, ma la domanda dell'esercizio è mal posta in quanto chiede di ristrutturare lo schema concettuale sulla base di tre operazioni che nulla hanno a che vedere con un'eventuale modifica di tale schema. La modifica può avere un senso al subentrare di nuove condizioni o relazioni tra le entità e non in base al numero di inserimenti o ricerche effettuate sulla base dati.
Come ti accennavo in precedenza non mi è ben chiaro cosa si voglia nell'esercizio 2. In pratica si chiede di ristrutturare lo schema concettuale ottenuto nell'esercizio 1 in base all'aumento del carico applicativo. A questo punto prova a postare o a descrivere il modo in cui hai risolto l'esercizio 1 in modo da poterlo migliorare nell'esercizio 2.
Non c'è alcuna riga SQL da scrivere in quanto si parla di schema concettuale che, successivamente (vedi esercizio 3) diventerà uno schma logico e solo in un secondo momento coinvolgerà l'SQL.
Nella progettazione della base dati, partendo dall'enunciato del problema io creerei sicuramente una tabella libri (iban, titolo, autore, curatore, anno) ed una tabella autori_curatori (codfisc, nome, cognome, telefono). Utilizzo una sola tabella in quanto gli attributi sono gli stessi ed in alcuni casi gli uni possono svolgere l'attività degli altri.
A questo punto vediamo che tra la tabella libri e la tabella autori_curatori sussiste una relazione n:m in quanto un libro ha almeno un autore ed almeno un curatore e lo stesso vale per autori e curatori. Ciò comporta l'introduzione di altre due tabelle di relazione aut_lib (iban_libro, codfisc_aut_cur) e cur_lib (iban_libro, codfisc_aut_cur) che relazionano appunto i libri con i rispettivi autori e curatori.
Sinceramente non capisco cosa viene chiesto nell'esercizio 2 in quanto è mia abitudine partire da uno schema ottimale che preveda a monte un cerco carico. L'esercizio 2 implica un'errata progettazione della base dati nell'esercizio 1.
@spatu said:
...
ragazzi sareste veramente gentilissimi se mi svolgeste la traccia cosi poi io tento di assimilarla il piu' possibile
...
[...]
Ora, se hai bisogno di una mano per risolvere il problema qui troverai molta gente preparata e disposta ad aiutarti, tra cui il sottoscritto, ma la pappa pronta non mi sembra il caso.
[...]
Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in c:\programmi\easyphp1-8\www\clienti_totali.php on line 38
alla funzione mysql_num_rows() è stato passato un argomento non valido!!! Essa si aspetta il resultset di una query, ma evidentemente non gli è stato passato ciò.
Ciò significa che le variabili $query1 e $query2 non sono resultset validi per cui l'unica spiegazione è che le query non sono andate a buon fine.
Capisco le richieste di aiuto, ma almeno metteteci un po' del vostro, basta leggere a volte per capire il problema.
@Fabrizio23 said:
Grazie, sì sì la tabella ce l'ho...ma quindi ho compilato male?
??? che significa "ho compilato male" ???
Immagino che tu abbia una tabella clienti nella quale vi sia una colonna che discrimina l'attualità o meno di un cliente. A questo punto i clienti attuali sono quelli che hanno quella colonna valorizzata con un particolare valore, mentre i clienti totali sono tutti quelli contenuti nella tabella clienti.
Comunque ti consiglio di leggerti un buon manuale in cui vengano descritte le basi concettuali prima ancora delle funzioni e delle istruzioni PHP e MySQL.
Resto basito...perchè mai i due script si dovrebbero comportare in maniera differente??? Solo perchè hai cambiato nome ad alcune variabili!?!?!?!?! Sono perplesso.