Pagina 2 di 3 primaprima 1 2 3 ultimoultimo
Visualizzazione dei risultati da 11 a 20 su 28
  1. #11
    Il GROUP BY serve per "raggruppare" dei dati e non per scegliere un record. Con GROUP BY e/o DISTINCT viene preso il primo record che viene fisicamente trovato e che soddisfi la condizione richiesta.

    Prova a fare un ordinamento prima della query con alter table....
    codice:
    ALTER TABLE arts ORDER BY catid DESC
    Per entrambe le tabelle ovviamente. Questo pero' lo devi ripetere sempre prima della query, perche' eventuali record aggiunti successivamente si troveranno sempre fisicamente al fondo cioe' in APPEND alla tabella stessa.



    @edit...

    i campi MAX() MIN() ecc... in realta' non esistono. Vengono formati dalla query e mostrati in unione al primo record incontrato nella tabella che soddisfa la richiesta. Non e' casuale, assolutamente. E' il primo che si incontra scorrendo la tabella.

    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  2. #12
    Originariamente inviato da piero.mac
    Il GROUP BY serve per "raggruppare" dei dati e non per scegliere un record. Con GROUP BY e/o DISTINCT viene preso il primo record che viene fisicamente trovato e che soddisfi la condizione richiesta.

    Prova a fare un ordinamento prima della query con alter table....
    codice:
    ALTER TABLE arts ORDER BY catid DESC
    Per entrambe le tabelle ovviamente. Questo pero' lo devi ripetere sempre prima della query, perche' eventuali record aggiunti successivamente si troveranno sempre fisicamente al fondo cioe' in APPEND alla tabella stessa.
    Non conoscevo questo comando Mysql... interessante!
    Ho notato cmq che quando si cancellano record che non stanno in fondo o all'inizio della tabella (ma che sono stati inseriti in un periodo intermedio) allora l'ordine viene perso, sballato irrimediabilmente se non utilizzando il comando OPTIMIZE TABLE dopo ogni DELETE (che cancella i buchi fatti dai DELETE).

    Quindi come già si è detto... utilizzare il group by senza altre forme di controllo intelligente e sperare che prenda il dato più recente è semplicemente fortuna.

  3. #13
    Originariamente inviato da platone
    Non conoscevo questo comando Mysql... interessante!
    Ho notato cmq che quando si cancellano record che non stanno in fondo o all'inizio della tabella (ma che sono stati inseriti in un periodo intermedio) allora l'ordine viene perso, sballato irrimediabilmente se non utilizzando il comando OPTIMIZE TABLE dopo ogni DELETE (che cancella i buchi fatti dai DELETE).

    Quindi come già si è detto... utilizzare il group by senza altre forme di controllo intelligente e sperare che prenda il dato più recente è semplicemente fortuna.
    In un certo senso questo e' vero. Dipende pero' dal tipo di tabella. Per esempio le InnoDB non presentano mai "buchi" e tutto l'aggiunto viene appeso, infatti non esiste l'OPTIMIZE TABLE per loro.

    Ma con l'ordinamento dell'indice vengono comunque chiusi tutti i buchi ed i record vengono scorsi con l'ordine richiesto. L'alternativa sarebbe costruire una tab temporanea con order by ... desc e fare la query su questa.

    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  4. #14
    Originariamente inviato da piero.mac
    In un certo senso questo e' vero. Dipende pero' dal tipo di tabella. Per esempio le InnoDB non presentano mai "buchi" e tutto l'aggiunto viene appeso, infatti non esiste l'OPTIMIZE TABLE per loro.
    anche questa non la sapevo...

    Ma con l'ordinamento dell'indice vengono comunque chiusi tutti i buchi ed i record vengono scorsi con l'ordine richiesto. L'alternativa sarebbe costruire una tab temporanea con order by ... desc e fare la query su questa.
    Al momento della UNION l'ordine viene perso di nuovo, perchè è come se venissero unite due tabelle con ordini differenti, quindi ancora una volta è impossibile.

    Invece l'idea di usare una tabella temporanea mi sembra davvero eccessiva. Piuttosto usa due query

    SELECT id, MAX(data) FROM.....

    SELECT .......... FROM ...... WHERE (id = \"".implode(" OR id = \"", $ID_RECORD_PIU_RECENTI)."\")

  5. #15
    piero.mac se faccio
    ALTER TABLE arts ORDER BY catid DESC
    ottengo il risultato voluto

    Ora la domanda diventa: questo tipo di query è performante su database MOLTO grossi (anche nell'ordine dei gigabyte)? Immagino di no

    Se il db è grosso ed eseguo spesso ALTER... ORDER deve ricalcolare ogni volta l'ordine, e ci mette ogni volta più o meno lo stesso tempo, oppure "sistema" solo i record non ordinati --> più spesso lo faccio e più performa?

    Se no, mi conviene usare MAX() nella query dato che 'data' è numerico? Come faccio, GROUP BY MAX('data') o diversamente?

    Intanto grazie a tutti

  6. #16
    Originariamente inviato da Petro_suse91
    piero.mac se faccio
    ALTER TABLE arts ORDER BY catid DESC
    ottengo il risultato voluto

    Ora la domanda diventa: questo tipo di query è performante su database MOLTO grossi (anche nell'ordine dei gigabyte)? Immagino di no
    Fallo senza preoccuparti.... per ordinare i dati ORDER BY usa SORT.... e se hai database nell'ordine dei gigabyte prendi in seria considerazione di usare un RDBMS che sia "camion".


    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  7. #17
    Originariamente inviato da Petro_suse91
    Se no, mi conviene usare MAX() nella query dato che 'data' è numerico? Come faccio, GROUP BY MAX('data') o diversamente?
    MAX(data) e' gia' il risultato di un raggruppamento. Non puoi usarlo per GROUP BY, al massimo lo potresti usare nella clausola HAVING.

    Ma non e' semplice da applicare HAVING....


    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  8. #18
    Originariamente inviato da piero.mac
    Fallo senza preoccuparti.... per ordinare i dati ORDER BY usa SORT.... e se hai database nell'ordine dei gigabyte prendi in seria considerazione di usare un RDBMS che sia "camion".

    Uhm, se mi dici di non preoccuparti io non mi preoccupo, però una vocina dentro di me dice "preoccupati che non sbagli"

    Una cosa che ho omesso di dire prima: quella query viene richiamata ogni volta che un utente fa il log-in. Due ALTER table ORDER BY (uno per 'cats' e uno per 'users_cats') ad ogni login o visualizzazione home utente.
    Il che potrebbe voler dire anche 2/300 'alter...order' nel giro di un minuto con 50 utenti loggati (ma magari poi diventano 500 o di più) e qualche refresh di pagina per ciascuno.
    Sto tranquillo comunque?

    Non so perchè, ho dentro la testa l'immagine di un server sql che fonde...

    Oppure, un'altra soluzione potrebbe essere riordinare le tabelle a intervalli regolari (mezz'ora o più) tramite CRON, e magari appendere i record dei nuovi INSERT all'inizio invece che alla fine (se c'è un modo per farlo), questo per avere la matematica certezza di pescare sempre i dati nuovi.

    Altri modi di fare ciò nella query non ce ne sono, eh?
    Tabella temporanea? Come siamo messi a prestazioni? (però qui avrei bisogno di qualche esempio pratico)

  9. #19
    Allora fallo solo quando serve....

    invece di ordinarlo prima di leggere ordinalo dopo che hanno scritto...

    insert ...
    alter table

    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  10. #20
    Infatti, mi pareva un po' strano in effetti

    Sicuramente riuscirò a trovare un modo per non eseguire l'ordinamento della tabella ogni quindicesimo di secondo Devo solo rivedere alcuni punti dell'applicazione.

    E se ogni tanto qualche utente non dovesse trovare proprio l'ultimissimo record... beh, pazienza nulla di vitale, sono solo notizie da leggere

    GRAZIE piero.mac e anche platone

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.