Pagina 2 di 3 primaprima 1 2 3 ultimoultimo
Visualizzazione dei risultati da 11 a 20 su 29
  1. #11
    Originariamente inviato da niubbo
    Ho provato mysqli_connect per aumentare le prestazioni... ma c'è una sostanziale differenza da questo punto di vista? Di sicuro sono riscritte da zero e pensate per il futuro le librerie con la "i"... poi non so...
    Ciao,
    sì c'è una sostanziale differenza e sarebbe bene usare le funzioni mysqli_ piuttosto che le funzioni mysql_ perchè mysqli è in grado di gestire:
    1. prepared statment (importanti anche per stilare codice sicuro al riparo da SQL injection)
    2. transizioni (fondamentali per siti con molti utenti che accedono al db molto spesso)
    3. ecc. ecc. (come ti hanno già illustrato)
    però msqli richiede quelche attenzione in più nello scrivere il codice...

    ---
    per la questione dei tuoi script
    una tecnica che puoi usare è mettere in un file la connessione al db e fare poi un include_once in ogni script che deve usare la connessione a quel punto avrai sempre una sola connessione aperta

    inoltre - secondo me - una classe che parla con il DB (a meno che non sia lei stessa una classe DAL che proprio gestisce la connessione col DB) non dovrebbe preoccuparsi di aprire e chiudere le connessioni al db, ma piuttosto ricevere la connessione già aperta come parametro del costruttore....


  2. #12
    Utente di HTML.it L'avatar di garakkio
    Registrato dal
    Dec 2011
    residenza
    Roma
    Messaggi
    480
    Però....

    - transazioni e non transizioni
    - require_once e non include_once. E comunque si faceva così 10 anni fa, oggi si può fare molto meglio
    - se una classe sul DB non si occupa nemmeno di aprire la connessione, tanto vale non usare le classi

    Tra l'altro non c'è bisogno di scrivere una classe per gestire il database e usare transazioni, prepared statement, eccetera: c'è già PDO http://it.php.net/PDO

  3. #13
    Originariamente inviato da garakkio
    Però....

    - transazioni e non transizioni
    - require_once e non include_once. E comunque si faceva così 10 anni fa, oggi si può fare molto meglio
    - se una classe sul DB non si occupa nemmeno di aprire la connessione, tanto vale non usare le classi

    Tra l'altro non c'è bisogno di scrivere una classe per gestire il database e usare transazioni, prepared statement, eccetera: c'è già PDO http://it.php.net/PDO
    perchè scomodare PDO se tanto in un progetto usi un solo database?

    PDO può starci in un progetto open source o che può essere messo in esecuzione in ambienti eterogenei, altrimenti, visto che non si cambia database server tutti i giorni, mysqli può benissimo fare il suo dovere senza anzi anteporre un ulteriore layer di astrazione.

    Per inciso, le funzioni mysql_ vengono oramai sconsigliate anche da php stesso e viene consigliata la migrazione a mysqli_, che poi si usi il procedurale o gli oggetti poco fa la differenza, con tutte le funzioni procedurali di php fa poco la differenza.

  4. #14
    Utente di HTML.it L'avatar di garakkio
    Registrato dal
    Dec 2011
    residenza
    Roma
    Messaggi
    480
    Originariamente inviato da Ratatuia
    perchè scomodare PDO se tanto in un progetto usi un solo database?

    PDO può starci in un progetto open source o che può essere messo in esecuzione in ambienti eterogenei, altrimenti, visto che non si cambia database server tutti i giorni, mysqli può benissimo fare il suo dovere senza anzi anteporre un ulteriore layer di astrazione.
    Ma tu paghi un tot al kilo per ogni livello di astrazione?
    O hai paura che il server non ti regga perché usi un oggetto in più?
    Non pensi che sia meglio fare subito qualcosa di scalabile, perché poi quando ti serve effettivamente di scalare è già pronto?

  5. #15
    Originariamente inviato da garakkio
    Ma tu paghi un tot al kilo per ogni livello di astrazione?
    O hai paura che il server non ti regga perché usi un oggetto in più?
    Non pensi che sia meglio fare subito qualcosa di scalabile, perché poi quando ti serve effettivamente di scalare è già pronto?
    no, semplicemente non sono dell'idea che one size fits all

    l'unico motivo per usare davvero PDO invece che Mysqli è la "portabilità" nei confronti del database server PHP-side.

    Ma ti basta già usare funzioni specifiche all'interno delle query che non ci sono, ad esempio, da in postgresql e in mysql sì, che cmq ti devi andare a rivedere un botto di roba (e in maniera molto più "fine" che delle semplici funzioni (che alla fine fanno più o meno le stesse cose)

  6. #16
    Utente di HTML.it L'avatar di garakkio
    Registrato dal
    Dec 2011
    residenza
    Roma
    Messaggi
    480
    La portabilità non è l'unico vantaggio di PDO.
    Innanzitutto ti costringe a usare oggetti, mentre mysqli purtroppo ha ancora degli alias di tipo procedurale.
    Poi, per esempio, supporta i parametri nominali, mentre mysqli ha solo quelli posizionali.
    In generale, comunque, le funzioni specifiche del singolo db andrebbero evitate, o comunque astratte ancora di più (io consiglio l'uso di un ORM)

  7. #17
    Originariamente inviato da garakkio
    La portabilità non è l'unico vantaggio di PDO.
    Innanzitutto ti costringe a usare oggetti, mentre mysqli purtroppo ha ancora degli alias di tipo procedurale.
    Poi, per esempio, supporta i parametri nominali, mentre mysqli ha solo quelli posizionali.
    In generale, comunque, le funzioni specifiche del singolo db andrebbero evitate, o comunque astratte ancora di più (io consiglio l'uso di un ORM)
    gli oggetti li puoi benissimo usare anche con mysqli, se non li usi vuol dire che non si hanno le esigenze nè le capacità per utilizzarle

  8. #18
    - transazioni e non transizioni
    ovviamente transazioni

    - require_once e non include_once. E comunque si faceva così 10 anni fa, oggi si può fare molto meglio
    Dipende: se sei in grado di di gestire lo script anche se manca la connessione al DB o se vuoi bloccare tutto.
    E comunque sì è vero si faceva così già 10 anni fa e questo è solo uno dei modi possibili che - IMHO - ha il vantaggio della semplicità e dell'immediatezza

    - se una classe sul DB non si occupa nemmeno di aprire la connessione, tanto vale non usare le classi
    Ah sì? e perché, poi?
    Che una classe debba per forza aprire una connessione al db e non possa ricevere come parametro di un suo metodo un connessione già avviata non l'avevo mai sentita...
    dire poi "tanto vale non usare le classi" è un'assurdità, il motivo per il quale uno usa o non usa le classi non ha praticamente nulla a che fare con il fatto che una classe sia poi usata per aprire o non aprire la connessione al db..

  9. #19
    Utente di HTML.it L'avatar di niubbo
    Registrato dal
    Jul 2004
    Messaggi
    692
    Io ho farro una classe per gestire la connessione e le query a Mysql, questa classe funzionava tutta tramite mysql_connect classico, volevo aggiornarla con mysqli e basta assai poco perché basta cambiare il costruttore ed il metodo per le query... solo che come vi ho detto avendola stra usata senza chiudere mai la connessione con mysqli il server mi schioppa... ho paura che dovrò intervenire in modo molto certosino... il fatto è che ci ho fatto tutto un CMS... e se trovo il modo di far capire al costruttore se c'è una connessione già aperta e faccio usare quella? Ovviamente dovrò usare un brutto trucco tipo una variabile di sessione mi sa... che dite? E' una cosa troppo sporca?
    Non si può niubbare per sempre...

    P.S. Ma perché i CSS non fanno quello che gli dico di fare.... aaaAAAAAAARGHHHHH!!!!!

  10. #20
    Utente di HTML.it L'avatar di garakkio
    Registrato dal
    Dec 2011
    residenza
    Roma
    Messaggi
    480
    Se vuoi proprio fartelo da solo, il modo più pulito è implementare il pattern factory

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.