ciao,

pietro09 ha scritto:

Ogni <img fa una richiesta al server che si traducono in 100 richieste al database (apertura e chiusura di 100 connessioni!)

Puoi evitare questo se nel database memorizzassi soltanto il nome dell'immagine. I dati binari, invece, andrebbero salvati su disco così che le immagini siano direttamente visibili su web dal loro percorso.

Se non puoi mettere in atto questa soluzione, che comunque comporta delle modifiche all'applicazione, allora puoi limitare il problema creandoti una cache. Ipotizzo che le immagini vengano servite al client per mezzo di un HttpHandler (o di una pagina web). Potresti fare in modo che l'HttpHandler, dopo aver recuperato i dati binari dal database, li salvi su file in una cartella a tua scelta. Alla prossima richiesta, l'HttpHandler eviterà di aprire una connessione al database perché i dati binari sono già disponibili su disco e si limiterà ad effettuare un redirect al file (o eseguirà un Response.WriteFile).

La cache va gestita. Quando l'amministratore aggiornerà l'immagine di un record, la tua applicazione dovrà preoccuparsi di rimuovere il file di cache che era stato creato dall'HttpHandler.

ciao

---

Modificato da BrightSoul il 18 dicembre 2011 21.44 -

Per la mia esperienza, ha senso salvare a db file che devono sottostare a permessi o visibilità particolari che vuoi gestirti da codice piuttosto che da IIS o permessi Windows (col vantaggio di non rompere le scatole al sistemista di turno se non hai la possibilità di farlo tu), nel tuo caso, se non hai problemi a mostrare le immagini a tutti, direi di evitare i blob. Io ne faccio grande uso, ma devo mostrare documenti riservati e solo se hai particolari permessi, inoltre effettuo ricerche Full-Text e venivo da un sistema a cartelle gestito su disco difficile da mantenere e monitorare (cartelle utenti con permessi assegnati ad altri utenti, ma non per tutti i file, insomma... una cosa complicata e che necessitava di una persona che quotidianamente si occupasse di questo). Nel mio caso, l'amministratore o chi pubblica nuovi documenti, decide chi può vederli e cosa può farne direttamente da un'interfaccia web.
Venendo al tuo problema, un'alternativa potrebbe essere quella di memorizzare una sola immagine (quella grande magari) e creare la miniatura al volo, via codice, così hai una tabella decisamente più snella ed un solo file da gestire, ma qui dipende dal criterio applicato per le due immagini.
ciao

ma infatti penso che per il tuo caso specifico non hai grandi vantaggi ad utilizzare campi blob.
Nel mio caso è fondamentale perchè mi facilita il controllo degli accessi ai file e i permessi su una struttura particolarmente complessa.
Oltre a questo vantaggio, ripeto, se devi archiviare documenti di altro genere (office o pdf in primis), hai il vantaggio di poter effettuare ricerche full-text al loro interno.
A completare il discorso, se non ricordo male ora, con Sql Server 2008 R2 (non ricordo se anche con la versione precedente), puoi archiviare i file su percorso fisico, ma gestirli da db, diciamo così, "indicizzandone" il contenuto (mamma mia che obbrobrio di espressione, ma spero ci siamo capiti :-P)
ciao

il concetto di unire tutte le immagini in una sola (sprite) può essere percorribile, anzi è consigliato ma bisognerebbe capire l'esigenza della tua applicazione.
In ogni caso, per esperienza, i file, se non è espressamente necessario, non li metterei mai sul db perchè a breve ti troveresti a dover gestire Giga e giga di roba
con relative problematiche di backup e accesso ai dati.

In accordo con quanto già letto quindi i file li terrei su IIS (eventualmente con una politica di accesso alle cartelle) e magari se possibile utilizzerei qualche strumento per rendere più leggere le immagini, in termini di dimensioni, in modo semiautomatico.

Esistono strumenti che in modo automatico generano degli sprite e li rendono disponibili alle applicazioni o in alternativa considera di utilizzare nel tuo IIS un expiration date per i contenuti in modo che le immagini non
vengano caricate ogni volta dal browser ma che vengano lette dalla cache.