Visualizzazione dei risultati da 1 a 5 su 5
  1. #1

    [PHP] meglio query o array per aggiornamento bi-verso di una tabella

    Bon Jour, ho una domanda che mi sollazza...
    E' puramente per curiosita' pero'...
    Avendo delle classi in PHP che girano in locale, quale scelta e' migliore se :
    Devo aggiornare un Database con un documento, in questo documento ci saranno tutti i prodotti presenti nella tabella da aggiornare del db, ma probabilmente vi saranno anche prodotti nuovi o prodotti cancellati che non si vedranno.
    Mentre per i prodotti nuovi pare molto molto semplice : si effettua una query per ogni prodotto e si vede se esiste, se esiste non si fa nulla, altrimenti lo si inserisce.
    Per i prodotti cancellati la cosa diventa piu' complessa, e mi fa' ricredere anche sulla prima tecnica.
    Avendo studiato che meno si utilizza una risorsa lenta (ok il db e' sullo stesso server, ma comunque e' piu' lento di un array) e meglio e', mi verrebbe in mente di effettuare una chiamata dove mi faccio restituire dal db solo le chiavi primarie queste chiavi verranno memorizzate in un array, avendo gia' creato un array del documento, dovro' solo confrontare i due array, e nel caso non trovassi coincidenze da array_documento-> array_db allora effettuerei una insert del valore presente nel primo db, nel caso invece non trovassi corrispondenze dall'array_db-> array_documento allora vorrebbe dire che e' stato cancellato un elemento e cio' dovrebbe essere eliminato dal mio db.
    Se dovessi farlo per mezzo di richieste al db, oltre doverne fare moltissime (contando anche quelle precedenti) credo avrei un inutile spreco di risorse, mentre in tale modo perdero' del tempo a caricarmi l'array del documento e del db ma potrei lavorare con dei tempi piu' veloci.
    Fatemi sapere la vostra.

  2. #2
    Ciao,
    Diciamo che potresti adottare varie strategie.
    Una potrebbe essere quella di implementare dei trigger che ad ogni azione IUD, ti va a controllare riga per riga il contenuto e gestisce le eccezioni da adottare.
    Un altra soluzione potrebbe essere quella di estendere la tua tabella creando un campo che ti serva da HASH...
    O in alternativa calcolarti l'HASH row al momento facendo una cosa del genere :
    Codice PHP:
    SELECT p.*, MD5(id,name,price,...) AS hashrow FROM products AS 
    Cosicchè tu vai a confrontare gli hash della tabella con quelli dei file, sapendo per certo quale riga esiste o meno.
    Ho una logica tutta mia, fatta di if else ...

  3. #3
    Utente di HTML.it L'avatar di Virus_101
    Registrato dal
    Sep 2008
    Messaggi
    2,497
    Si e' una soluzione.

    Una ltra sarebbe aggiungere una flag di stato(nel caso opportunamente indicizzata) in modo che se il prodotto e' riconosciuto come cancellato venga flaggato come tale.

    Ora la domanda sorge, sta bene ottimizzare tebelle et operazioni, ma in totlare quanti prodotti hai ?
    Se non hai troppi prodottie i tempi di esecuzioni sono "umani" unitamente al fatto che questa procedura credo verreebe eseguita non troppo frequentemente ... un truncate table + scansione oggetti + insert ? (domando poiche non so come e' strutturato, ovviamente se quei prodotti sono linkati in altre tabelle / risorse non farlo o perdi tutti gli indici)

  4. #4
    Perfetto, cioe', come controllare che una riga esista o meno io lo faccio direttamente con la chiave primaria della tabella, che sara' contenuta anche nel file excel, il mio era piu' un problema teorico, cioe' spendo piu' risorse a tirarmi fuori con una "select chiave univoca from tabella" tutte le chiavi salvandole dentro ad un array e poi mi controllo l'array e poi vado a fare un match tra array delle chiavi del mio file e array delle chiavi della tabella (in tale modo saprei quali son prodotti nuovi (presenti nell'array del file ma non nella tabella) e quali prodotti vecchi (presenti in array tabella ma non array file)...oppure spendo meno risorse a farmi un array delle chiavi dell'excel su quello vado a farmi tante query al db quanti sono i prodotti (all'incirca si parla nell'ordine di grandezza delle migliaia), cosi' individuo i prodotti nuovi e li inserisco, per i prodotti vecchi invece sarei comunque costretto a tirarmi fuori una alla volta le chiavi dalla tabella (in questo caso con una query) e poi andrei a fare un controllo sull'array delle chiavi primarie del file, se non presente anche qua' ci sarebbe una cancellazione "virtuale" cosi' riuscirei comunque a mantenermi uno storico.
    Effettivamente questa procedura dovrebbe girare una volta al mese (quindi non avrei problemi di "tempo"...pero' vorrei capire come renderla piu' performante visto che gli array pesano in memoria, ma le query mi pesano sulla risorsa seppur la connessione venga fatta una volta sola, a me hanno sempre insegnato che bisogna utilizzare il meno possibile le risorse esterne, pero' il db si trova nello stesso punto dove si trova lo script, quindi non ci sarebbero latenze dovute alla banda e quant'altro...MHA

  5. #5
    Utente di HTML.it L'avatar di Virus_101
    Registrato dal
    Sep 2008
    Messaggi
    2,497
    Guarda da questo punto di vista parti sapendo che una insert pesa piu' di una select.
    Una select con filtri su colonne non indicizzate e magari testuali+ eventuali ordinamenti pesa piu' di una select normale...

    Per il resto devi fare dei test

    Codice PHP:

    $inizio 
    microtime(true) ;

    // CHIAMA FUNZIONE DI TEST1

    echo "FUNZIONE DI TEST 1 ESEGUITA IN ".(  microtime(true)-$inizio  )." secondi " ;

    // ETC PER I VARI TEST 
    FAi una profilazione del genere e vedrai.
    Magari nel frattempo tracci pure la memoria usata e altri dati(sempre prendendo in cosiderazione che le echo pesano parecchio nei tempi di esecuzione ).


    Secondo me devi farti dei test dio questo tipo controllando i tempi delle query e i tempi del php, fai il test così :

    Pochi dati
    - caso migliore - con i dati apposto
    - caso medio - dati mediamente incasinati
    - caso peggiore - la peggio situazione possibile

    Molti dati
    - caso migliore - con i dati apposto
    - caso medio - dati mediamente incasinati
    - caso peggiore - la peggio situazione possibile

    Ti segni i tempi e fai le relative estrapolazioni e vedi cosa ti conviene.

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 © 2024 vBulletin Solutions, Inc. All rights reserved.