Newsgroup: it.comp.software.database
Titolo: [sql] mysql: distinct su un campo solo

utilizzo una vecchia versione di mysql (mi pare 4.0.18) e ho un problema:
la mia tabella utente contiene: id, nome, cognome, telefono, ecc.
per motivi che non sto a spiegare si potrebbe verificare un simile caso:
row 1:carlo, rossi, 02-44556677
row 2:carlo massimo, rossi, 02-44556677
facendo un distinct in questa maniera:
select distinct telefono, nome, cognome from utente
ottengo entrambe le righe (perchè varia il nome)
mentre facendo:
select distinct telefono from utente
ottengo una sola riga
a me servirebbe di ottenere cmq solo 1 riga (è indifferente quale) perchè
il numero di telefono è lo stesso; insomma dovrei in qualche maniera fare
un distinct sul telefono che però mi tiri fuori anche gli altri dati
come faccio???(non posso usare le query annidate per via della versione di
mysql)
grazie
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
SELECT nome, cognome, telefono FROM tabella GROUP BY telefono;
In MySQL funziona restituendo nome e cognome a caso.
Nei database relazionali solitamente non si possono selezionare campi non ragruppati in una query con GROUP BY (il
risultato non è determinato).

 mysql)
Questa te la prende?
SELECT MIN(cognome) as cognome, telefono FROM Tabella Group By Telefono
Al posto di questo [MIN(cognome)] magari concateni nome e cognome
Oppure
SELECT campi FROM tabella WHERE IDTABELLA IN (SELECT MIN(IDTABELLA) FROM
tabella GROUP BY TELEFONO)
La seconda è meno performante ma ti tira fuori tutti i campi che vuoi, di
là dovresti concatenare tutto, non credo che la Min(nome),Min(cognome)
funzionino, ma prova

Zac ha scritto:

ok grazie
un'altra cosa: non posso fare un order by all'interno del group by??
insomma al posto di fargli tirare fuori una riga a caso fargli prendere
magari quella con la data di nascita più recente??
se metto order by data alla fine della query ordina per data ma sulle
righe alle quali è già stata applicata la group by e quindi non funziona
grazie
che intendi dire con "Nei database relazionali solitamente non si possono
selezionare campi non ragruppati in una query con GROUP BY" ?


Andrea [Work] ha scritto:





la seconda no perchè è troppo vecchia la versione di mysql; la prima è
uguale (+o-) a quanto detto da zac, no?


 selezionare campi non ragruppati in una query con GROUP BY" ?
ho capito che intendi dire
e come mai in mysql si riesce?


 e come mai in mysql si riesce?
Evidentemente non è un database relazionale... ;)
Comunque il fatto che permetta di scrivere questo tipo di query potrebbe sembrare un vantaggio ma, in realtà, se ti
trovi a scrivere query più complesse e sbagli, ad esempio, i nomi dei campi non è molto vantaggioso:il server
restituisce comunque un risultato (casuale) al posto di segnalarti che hai fatto una richiesta non corretta...
Comunque per mysql è un approccio standard eseguire operazioni non richieste anche se si fanno richieste assurde: prova
ad inserire in un campo data una data errata (es 2006-01-32), la inserisce senza fiatare ma poi ti ritrovi 0000-00-00.

 restituisce comunque un risultato (casuale) al posto di segnalarti che hai
fatto una richiesta non corretta...
ok ma questo tipo di query a me sembrano funzionare e mi torna comodo; che
controindicazioni ci potrebbero essere (a parte la cosa dei nomi dei
campi)??
insomma i risultati che restituisce sono sicuramente conformi alla mia
richiesta del primo post??
rinnovo questa domanda:
non posso fare un order by all'interno del group by??
insomma al posto di fargli tirare fuori una riga a caso fargli prendere
magari quella con la data di nascita più recente??
se metto order by data alla fine della query ordina per data ma sulle
righe alle quali è già stata applicata la group by e quindi non funziona
grazie zac


 righe alle quali è già stata applicata la group by e quindi non funziona
Se la domanda è "selezionare all'interno di ogni ragruppamento di numeri i nomi delle persone che hanno la data di
nascita più recente" penso che non si possa risolvere senza le subquery.
Probabilmente si può fare con una tabella temporanea (usando quindi due query separate)... una cosa del tipo (da provare)
CREATE TEMPORARY TABLE temp AS
SELECT telefono, min(data_nascita) AS data_nascita
FROM tabella
GROUP BY telefono;
SELECT
t.nome, t.cognome, t.telefono
FROM
tabella AS t
JOIN temp ON (t.telefono = temp.telefono AND t.data_nascita = temp.data_nascita);
N.B. funziona solo se la data di nascita distingue univocamente i nomi con lo stesso telefono. Se due nomi hanno la
stessa data e lo stesso telefono devi aggiungere ulteriori campi che li possano distinguere.
Ciao

 uguale (+o-) a quanto detto da zac, no?
La prima è diversa, perchè in quella di Zac ci sono campi senza group By o
aggregazioni nella select, nella mia in ogni campo metti o Min/Max ecc. e
poi telefono.
Quella di Zac su Firebird non mi funziona perchè vuole che ogni campo della
select sia nel group by o abbia una min/max/sum ecc.
SELECT nome, cognome, data,telefono .... GROUP BY TELEFONO
Mentre questa è standard come sintassi (o almeno credo):
SELECT MIN(nome), MAX(cognome), MIN(data),telefono .... GROUP BY TELEFONO

 Ciao
ho dovuto modificarla così (telefono e data di nascita non bastano):
 CREATE TEMPORARY TABLE temp AS
 SELECT idRow, telefono, min(data_nascita) AS data_nascita
 FROM tabella
 GROUP BY telefono;
 SELECT
 t.nome, t.cognome, t.telefono
 FROM
 tabella AS t
 JOIN temp ON (t.idRow= temp.idRow AND t.telefono = temp.telefono AND
t.data_nascita = temp.data_nascita);
l'idRow è univoco; non mi funziona
penso dipenda dal fatto che se fai 
SELECT idRow, telefono, min(data_nascita) AS data_nascita
 FROM tabella
 GROUP BY telefono;
tira fuori un idRow e una data_nascita apparteneneti a 2 righe diverse
tra l'altro vorrei sapere una cosa; come si usa in uno script php la
tabella temporanea, eseguo la prima query (quella ch crea la tab temp) e
poi la seconda?
grazie della pazienza


Andrea [Work] ha scritto:





grazie


 gli altri dati come faccio???
A parte che non ho idea di come possa essere equivalente restituire
dati a random, un problema ulteriore è che adesso non puoi
distinguere più utenti che condividono lo stesso numero di telefono
(o sembrerà un errore di inserimento).
Inoltre, fare affidamento a sintassi o "feature" non standard ti
pone sotto alla sedia una bomba che attende solo di esplodere alla
prossima update o migrazione.
Anche se, come al solito, il problema di fondo è quanto valgono i
dati.

 inserisce senza fiatare ma poi ti ritrovi 0000-00-00.
Però è veloce. LOL

 poi la seconda?
Penso di si. Se la connessione è persistente le tabelle temporanee non dovrebbero scomparire... ma non conosco bene
PHP.... forse qualcun'altro può risponderti con più precisione (oppure basta provare...)
Ciao

 Però è veloce. LOL
Come diceva qualcuno (purtroppo non ricordo più dove l'ho letto):
"cosa me ne faccio di un database veloce che mi fornisce risposte sbagliate?"

 sbagliate?"
Quoto e sottoscrivo.
Spesso si trascura che se il dbms è veloce, lo è proprio perché
vengono saltati i controlli di integrità, barattando in tal modo
qualità con velocità.
Inoltre, il giorno che verranno aggiunti tutti i controlli richiesti,
c'è da giurare che il dbms non sarà affatto più veloce di un qualunque
altro prodotto similare...

 meglio desistere... :-)
Ecco bravo, desisti. Magari datti uno sguardo alla documentazione, potresti
persino accorgerti che il livello di controllo sull'integrità lo puoi
modulare sulla base delle tue esigenze. Magari per un semplice e veloce db
prevalentemente in sola lettura potrebbe essere un vantaggio quello di
spuntare qualche secondo nella risposta ad una query...
Torno a ripetere, se non sei in grado di cogliere il senso di un trade-off e
meglio che vai su altra classe di prodotti. Sempre che funzionino
esattamente e sempre secondo specifiche.
Sandro.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 se non sei in grado di cogliere il senso di un trade-off e meglio
Gią, ma per fortuna che posso contare su menti illuminate che lo
capiscono...


Non si tratta di menti illuminate, ma molto più semplicemente di persone,
come me, che riescono a dedicare, senza esagerazione, il 90% del proprio
tempo a studiare, provare, testare, confrontare. E che poi, quando mettono a
disposizione su usenet la propria (neanche tanto misera) esperienza si
sentono anche dare del coglione.
Io per mestiere progetto sistemi e disegno architetture. Per me una
soluzione passa anche dalla scelta dello strumento, sulla base di svariati
altri requisiti oltre alle features in senso stretto, quali costi,
semplicità d'uso e manutenzione, supporto, spread-knowledge, ecc...
Spero di essere stato sufficientemente chiaro. Sennò provo a farti un
fumetto.
Sandro, il troll morpher.


 
Il problema è che gli sviluppatori di MySQL in passato hanno fatto
alcune dichiarazioni che hanno lasciato molti esperti di database senza
parole.
In particolare sulla inutilità delle foreign key, perchè tanto i
controlli li deve fare il client.
Infine MySQL é stato progettato con delle precise finalità (layer simil
SQL su ISAM) e nel tempo sono state migliorate alcune cose.
Il problema è che, a meno di una riscrittura totale, MySQL si porterà
dietro quelle limitazioni per sempre, lo stesso come accade in Windows
che si porta delle limitazioni risalenti al DOS.
Visto che oggi posso scegliere un database come PostgreSQL che è stato
pensato dall'inizio per essere un vero database relazionale (e con il
tempo è stato ottimizzato), perchè mai dovrei usare MySQL?
PostgreSQL ha anche una licenza migliore e ci sono compagnie esterne che
forniscono assistenza.
Se voglio un database veloce uso SQLite, pensato per essere un semplice
database embedded.
P.S.
Io sono uno sviluppatore e ho avuto modo di vedere in dettaglio come
sono stati progettati i protocolli di rete di MySQL e PostgreSQL e ti
posso dire che quello di MySQL mi ha lasciato molto perplesso.
Saluti  Manlio Perillo


Rispetto il tuo punto di vista, tanto più che non sono in alcun modo
collegato a MySQL ;-)
Ciao, Sandro.


 
Io invece preferisco affidarmi a soluzioni più solide.
Cercando con impegno si trovano hosting che supportano PostgreSQL;
probabilmente in futuro le cose andranno meglio, ma io mi sto orientando
verso i virtual server.
Saluti  Manlio Perillo

 fumetto.
Vedo che persisti, ma continua pure; che ci guadagni? Certe
affermazioni fanno male a chi le dice, non certo a chi le riceve.


Senti The man with two come cazzo ti chiami ... perchè non la finisci di
fare l'isterico è proviamo a confrontarci su questioni un attimo più in
topic?
Sandro.


 Senti The man with two come cazzo ti chiami ...
*PLONK*