HeDo (Founder Member)
Guru^2
Messaggi: 2765
Iscritto: 21/09/2007
|
Postato originariamente da pierotofy:
Mi trovo in disaccordo... un database permette di memorizzare dati binari e files sono dati binari, quindi a meno che non si fa un discorso contestualizzato di performance (nei quali un database potrebbe anche vincere, in base al contesto) non c'e' nessun problema. |
|
|
|
pierotofy (Admin)
Guru^2
Messaggi: 6230
Iscritto: 04/12/2003
|
Questa e' l'opinione di un utente (per altro datata) che ha esposto gil svantaggi, ma si e' dimenticato di parlare dei vantaggi.
Tenere traccia dei files su un filesystem in collegamento al database e' un livello di complessita' aggiuntivo; devo infatti sempre ricordarmi di eliminare il file corrispondente al record che elimino e non ci sono metodi per impedirmi di cancellare il record senza cancellare il file o viceversa. Analogalmente se rinonimo un file dovro' ricordarmi di aggiornare il percorso nel database. Oppure se lo modifico, dovro' ricordarmi di aggiornare le dimensioni, ecc. ecc.
Qui l'utente parla di uno scenario ben preciso, memorrizzare immagini in un database e visualizzarli in una galleria. E' ovvio che un'accesso individuale ad ogni immagine tramite uno singolo script causera' dei rallentamenti notevoli; duh! Un sistema piu' furbo terrebbe su disco una cache dei files presenti nel database (ma a quel punto utilizzerei la combinazione filesystem + database). E' uno di quei scenari dove usare solamente un database e' probabilmente sbagliato.
Questo non e' un problema se per esempio offro il download di un singolo file tramite un collegamento al database. Il rallentamento di un download e' infatti dato dalle dimensioni del file, non da quanto veloce il server mi risponde che il file esiste.
Il fatto che puoi vedere i files senza bisogno di uno script e' un vantaggio, ma ci sono situazioni in cui probabilmente non mi interessa avere accesso diretto ai files e la minor complessita' di gestire i files solamente nel database e' una soluzione migliore.
Poi mi sarebbe interessato sapere la tua opinione, non quella di "vincent".
Ultima modifica effettuata da pierotofy il 22/07/2012 alle 17:15
|
|
|
HeDo (Founder Member)
Guru^2
Messaggi: 2765
Iscritto: 21/09/2007
|
la mia opinione è quella di "vincent" 
rimango dell'opinione che è una pratica scorretta dal punto di vista logico, non tolgo che funzioni ma sinceramente è un sintono di bad design.
e se per caso ti chiedono un link al file? che fai realizzi uno script php che fa una query per ottenere i dati binari e poi li invia al client? che razza di senso ha, un bel link diretto e passa la paura
|
|
|
pierotofy (Admin)
Guru^2
Messaggi: 6230
Iscritto: 04/12/2003
|
Giusto, serve uno script. E metti caso che invece di condividere devo permettere l'accesso al file solamente ad un certo numero di utenti, cosa faccio?
Cioe', ci sono scenari in cui memorizzare su un database e' sconveniente, ma ci sono altri per cui e' conveniente. Spero su questo riuscirai a concordare...
|
|
|
HeDo (Founder Member)
Guru^2
Messaggi: 2765
Iscritto: 21/09/2007
|
Postato originariamente da pierotofy:
Giusto, serve uno script. E metti caso che invece di condividere devo permettere l'accesso al file solamente ad un certo numero di utenti, cosa faccio?
Cioe', ci sono scenari in cui memorizzare su un database e' sconveniente, ma ci sono altri per cui e' conveniente. Spero su questo riuscirai a concordare... |
nel nostro campo mai niente è totalmente sbagliato o totalmente corretto.
Come ho già detto, memorizzare un file in un database *funziona*, ma non per questo deve essere considerato una buona soluzione.
Esistono scenari in cui le soluzioni sono intercambiabili, ma devi ancora convincermi sul fatto che esista uno scenario in cui è *preferibile* adottare una memorizzazione nel database a confronto di una nel filesystem.
Mi dispiace, ma lo vedo come un uso improprio dello strumento, i database sono fatti per memorizzare dati relazionali (se rimaniamo nell'ambito mysql), not bunches of binary data
comunque la regolazione degli accessi o il contatore di download implicano comunque che quando un file venga scaricato uno script venga anch'esso eseguito. Ma concorderai con me che è singolare che sia proprio lo script a dover scaricare dal db i dati del file, anzi, è assurdo! Ultima modifica effettuata da HeDo il 23/07/2012 alle 16:34 |
|
|
pierotofy (Admin)
Guru^2
Messaggi: 6230
Iscritto: 04/12/2003
|
In certi casi, come ho scritto prima, usare solo un database e' meno complesso... meno complessita' non e' una soluzione preferibile in certe situazioni?
|
|
|
cybercross (Normal User)
Newbie
Messaggi: 4
Iscritto: 18/07/2012
|
Scusate se ho tardato nella risposta, comunque ho risolto modificando del tutto il codice e salvando i file in una cartella del server!
Era altervista che imponeva dei limiti! 
Grazie a tutti per le risposte!
|
|
|
Vincenti Aldo (Ex-Member)
Newbie
Messaggi: 18
Iscritto: 18/01/2012
|
Scusate se sto riesumando questa discussione.
Sono completamente d'accordo con HeDo. Io ho sempre utilizzato il Database per memorizzare immagini ma ultimamente ragionandoci sono arrivato alla conclusione che conviene memorizzare foto su cartelle. Espongo il mio ragionamento:
1. Perché Facebook (dove vengono caricare più di 250 milioni di foto al giorno) salva le immagini sulle cartelle invece di utilizzare il database? Vuol dire che in termini di prestazioni conviene usare le cartelle.
2. Molti Hosting Condivisi, anche professionali (non voglio fare nomi), impongono 100 mb per database. Ipotizzando che una foto pesa 1 MB nel mio sito si possono memorizzare solo 100 foto? Meglio usare le cartelle dove non ci sono limiti imposti particolari (oltre la capienza dell'hard disk del server).
3. Come ha detto HeDo "e se per caso ti chiedono un link al file? che fai realizzi uno script php che fa una query per ottenere i da
ti binari e poi li invia al client? che razza di senso ha?".
In rari casi comunque per questione di comodità è meglio usare il database. Ma per le immagini non ha senso. Ad esempio, io nel mio nuovo progetto per memorizzare le immagini utente uso questo meccanismo:
1. Quando l'utente si registra genero un codice alfanumerico che viene messo sul database, questo codice è il nome della cartella che verrà generato su foto (vale a dire la cartella utente dove verranno messe le foto).
2. Quando si caricano le foto prendo il codice dal database della cartella dell'utente e creo un ulteriore cartella dentro la cartella per ogni foto caricata e poi metto il percorso completo sul database.
Ad esempio, se si caricano due foto a.jpg e b.jpg:
i percorsi saranno:
$codicecartellautente/$codicegeneratoalmomento/a.jpg e $codicecartellautente/$codicegeneratoalmomento/b.jpg
Che ne pensate di questo intervento?
|
|
|
