Printable View
Vorrei sapere cosa c'è di sbagliato in questa query:
Mi restituisce sempre:Codice:SELECT * FROM contests
LEFT JOIN contests_participants
ON (participant_id = 2) AND (participant_contest = contest_id)
UNION
SELECT COUNT(participant_id) AS participants
FROM contests_participants
GROUP BY participant_contest
Dovrei contare un certo dato raggruppandolo per id. Se avete altre soluzioni sono tutto orecchi :mrgreen:Citazione:
The used SELECT statements have a different number of columns [#1222]
Quando esegui la UNION i record restituiti dalle due query devono essere "compatibili per unione", ovvero non solo avere lo stesso numero di campi ma anche i rispettivi domini (numerico intero, numerico decimale, stringa e simili) nella stessa posizione. Questo perché il risultato sarà una singola tabella dove confluiranno i risultati delle due query, con la condizione che saranno inseriti nel recordset risultante se soddisfano almeno una delle due query (se utilizzassi INTERSECT le dovrebbe soddisfare entrambe).
Per correggerti la query però sarebbe meglio che fornissi altre informazioni, come la struttura delle tabelle coinvolte: così potresti anche definire meglio qual è il record che devi contare...
Stammi bene...
Allora, ho una tabella dove ci sono i dati di un concorso con 8 campi, nella seconda tabella ho due campi dove registro l'id dell'utente e l'id del concorso.
Quando sono nella lista dei concorsi devo scrivere per ogni concorso quanti utenti partecipano (credo per questo sia utile il GROUP BY) per ogni concorso. Ecco un esempio:
prima tabella:
La seconda:Codice:contest_id contest_name contest_type contest_status contest_start contest_finish contest_open contest_winner
1 Prova 1 0 1257977977 1287698400 2 2
2 Prova 1 0 1257977977 1257987000 2 2
Nella listm, attraverso un while, mostro tutti i concorsi presenti nella prima tabella, quindi devo contare quanti utenti partecipano (nella seconda).Codice:participant_id participant_contest
2 1
2 2
Capito il mio problema?
Credo che nella seconda tabella tu abbia sbagliato il nome dei campi oppure il loro contenuto (non possono esserci due ID uguali)
Ciao!
Se vuoi usare solo l'ID dei concorsi, basta usare la seconda tabella:La JOIN (o la WHERE in vecchio stile) ti serve se vuoi anche il nome del concorso:Codice:SELECT participant_contest, COUNT (*)
FROM contest_participants
GROUP BY participant_contest
Stammi bene...Codice:SELECT participant_contest, contest_name, COUNT (*)
FROM contest_participants, contests
WHERE participant_contest = contest_id
GROUP BY participant_contest, contest_name
Non sono ID auto increment, ma sono ID che registrano l'utente e il concorso, poi attraverso un indice di tipo PRIMARY evito che ci siano contenuti doppi.
La query che mi mostra la lista di tutti i concorsi è questa:
Poi come scritto, in un while li mostro tutti.Codice:SELECT * FROM contests
LEFT JOIN contests_participants
ON (participant_id = 2) AND (participant_contest = contest_id)
Ora, per ogni record della tabella contest, devo contare quanti utenti partecipano. Quindi, per non fare un'altra query nel while per ogni concorso, mi pare strano non ci sia soluzione simile a quello che vorrei.
Con la seconda query chehai postato mi mostra solo i concorsi dove ci sono partecipanti, non tutti i concorsi.
Grazie del supporto :wink:
Potresti provare quindi così:Se non funzionasse (perché ti conta per 1 anche i record con la parte sinistra a NULL), non puoi fare altro che estrarli manualmente con la UNION:Codice:SELECT participant_contest, contest_name, COUNT (*)
FROM contest_participants RIGHT JOIN contests ON participant_contest = contest_id
GROUP BY participant_contest, contest_name
(la query dovrebbe essere corretta, ma non credo MySQL 4 installato su AV supporti le query annidate).Codice:SELECT participant_contest, contest_name, COUNT (*)
FROM contest_participants, contests
WHERE participant_contest = contest_id
GROUP BY participant_contest, contest_name
UNION SELECT contest_id, contest_name, 0
FROM contests
WHERE contest_id NOT IN (SELECT participant_contest FROM contest_participants)
Stammi bene...
Ora lavoro in locale con MySQL 5.1.37, mentre in remoto ho la 5.0.82, ma credo che inizierò su AV e forse ci sarà anche l'aggiornamento prima che finisca lo script :lol:
La seconda query l'ho modificata leggermente e funziona, solo che mi mostra nel campo contest_id il seguente record: [BLOB - 1B] o [BLOB - 7B] e poi mi mischia i dati, cioè nel while quando li mostra inverte l'id con il nome quindi mi incasina anche la generazione del link :shock:
Scusa, ma come ho già sritto in altri topic sono duro di comprendonio, ma la voglia di imparare è abbastanza :oops:
Io sopra ho assunto (credo ragionevolmente, anche se non me l'hai scritto) che:
- participant_contest (tabella contest_participants) sia una chiave esterna per il campo contest_id (tabella contests)
- entrambe siano di tipo numerico intero
È corretto, o c'è qualcosa che mi è sfuggito?
Se così è, non riesco a capire né perché ti venga riconosciuto come un BLOB (oggetto binario), né tantomeno perché ti scambi le colonne (che devo aver dichiarato in modo che siano "compatibili per unione").
Stammi bene...
La prima tabella (contests) ha tutti i dati dei contest, la seconda (contests_partecipants) invece raccoglie gli utenti iscritti. Per sapere a quli contest un utente si è iscritto ovviamente devo inserire l'id dell'utente e quello del concorso.
Ora, siccome nella seconda tabella avrò obbligatoriamente record uguali, ma non righe uguali, cioè non potrò avere lo stesso utente iscritto due volte allo stesso contest, avrei voluto contare gli utenti iscritti in ogni contest nella stessa query che li prende e li mostra nella lista.
Faccio un altro esempio:
Una stanza di un forum ha tanti argomenti dentro. Ora, per sapere che quegli argomenti sono di quella determinata astanza, nell'argomento salvi anche l'id della stanza.
Quando vai a mostrare la lista delle stanza, senza eseguire in più una query per ogni stanza in modo da contare gli argomenti, è possibile fare questo nella query che seleziona queste stanze?
Ok, fino a qui ci siamo: l'id dell'utente e l'id del concorso sono chiavi esterne verso le rispettive tabelle (perché l'id del concorso deve essere presente come id nella tabella dei concorsi, questo è il significato)Citazione:
Originalmente inviato da biccheddu
Se ho capito bene il problema, non puoi farlo con una singola query: te ne serve una per visualizzare il riepilogo, e un'altra per visualizzare i dati dei singoli iscritti. Quest'ultima puoi realizzarla mantenendo tutti i dati nella stessa tabella ed eseguendo un preciso ordinamento, mantenendo vicini i record che vanno elaborati insieme: in questo modo, saprai che dovrai passare al concorso successivo quando, scandendo la lista, "si rompe" questo criterio.Citazione:
Originalmente inviato da biccheddu
La prima query te la dovrei aver scritto sopra, se mi confermi che funziona.
La seconda, invece, l'hai scritta tu o quasi: se togli la condizione sui partecipanti, dovresti riuscire, elaborando le due query "in parallelo", a distinguere quali sono i concorsi senza partecipanti (perché hanno il contatore della prima query pari a 0).
Stammi bene...
Che casino, non ci capisco niente, mi sa che creerò un campo nella tabella dei contest che verrà incrementato e basta, tanto non ci si può cancellare dal concorso, mi semplifico la vita no?
Puoi fare anche così, è una soluzione molto usata: si chiama ridondanza.Citazione:
Originalmente inviato da biccheddu
Attento, però, le ridondanze sono delle "armi a doppio taglio": semplifichi qualche elaborazione, ma il costo è quello di un aggiornamento che deve essere fatto sempre "in parallelo", pena l'inconsistenza dei dati (ovvero, ottieni dati non corrispondenti alla realtà).
Stammi bene...
Cioè? non ho capito quel che intendi.
Esempio stupido: phpBB salva nella tabella dei topic il numero di risposte e il reale numero di risposta (cioè il numero di risposte senza quelle non approvate ecc).
Ogni qual volta che un utente si iscriverà basterà fare un incremento del dato no? Questo sarà in ogni riga della tabella.
È proprio questo il problema a cui mi riferivo: gestire delle ridondanze su un database richiede che ci si faccia carico di tutte le operazioni, sia durante l'inserimento che durante la cancellazione.Citazione:
Originalmente inviato da biccheddu
Tipico esempio realizzato sui forum è il contatore dei messaggi: di solito viene implementato per ridondanza, perché contare le righe di una tabella solo per stampare un numero è un lavoro eccessivamente gravoso. Questo, però, ti richiede due operazioni ad ogni invio o cancellazione di un messaggio: una per il messaggio vero e proprio, e l'altra per aggiornare il contatore.
Prima di inserire una ridondanza sul database, ti conviene eseguire delle valutazioni: se il numero di operazioni supplementari necessarie a gestire la ridondanza (di solito gli aggiornamenti) è minore degli accessi al dato ridondato (di solito le ricerche), allora è conveniente gestirla. Per calcolare il numero di operazioni, devi fare una stima degli utenti e delle loro azioni, nel tuo caso:
- quanti utenti accedono alla tua applicazione?
- quanti si iscrivono ad un concorso?
- quanti, invece, sono "interessati" a conoscere il numero di iscritti di un concorso?
Stammi bene...
Questo dipende, io sto creando il sito e spero un giorno sia frequentato perchè non ci sono molti di questi che hanno quello che sto creando, quindi le prime due dipendono da quanto appena detto, mentre la terza credo che dipenda da una cosa: un concorso molto gettonato porta altra gente ad iscriversi, però effettivamente potrei mostrare il numero nella pagina apposita del concorso quando mostro tutti gli utenti iscritti. In questo modo risparmierei un campo per ogni concorso, un dato in meno da estrarre e una query in meno quando un utente si iscrive al concorso, credo sia molto tutto questo.