Tabella separata per immagini o campo img in tabella ?

di il
16 risposte

Tabella separata per immagini o campo img in tabella ?

Ciao a tutti
sono alle prese con la progettazione di un database per la raccolta di info e foto di una serie di prodotti eterogenei raggruppati in categorie per ognuna delle quali è stata creata una tabella. Volendo evitare di riservare uno spazio immagine all'interno di ciascuna di queste tabelle perchè potrebbe rimanere inutilizzato, vi chiedo se non sia più conveniente utilizzare una sola tabella per memorizzarle tutte piuttosto che inserire un campo in ciascuna tabella come avevo pensato di fare. Se secondo voi è meglio creare una tabella separata per le immagini, come procedere per identificare la tabella e il prodotto a cui l'immagine appartiene ?
Grazie per l'aiuto
Giuseppe

16 Risposte

  • Re: Tabella separata per immagini o campo img in tabella ?

    Potresti descrivere tutto più dettagliatamente?
    - nomi propri tabelle
    - nomi propri dei campi di ogni tabella
    - rispiegare il problema
  • Re: Tabella separata per immagini o campo img in tabella ?

    Prima di tutto è fondamentale sapere di quale database parliamo:
    di tipo Server (SQL Server, Oracle, ...) oppure Desktop (Access, SQLite, ...)
  • Re: Tabella separata per immagini o campo img in tabella ?

    Il tipo di dato BLOB in generale (ma non sono sicuro che sia sempre così, dovresti dirci che DBMS usi) è a lunghezza variabile, il che vuol dire che se un campo è vuoto occupa solo lo spazio necessario per indicare che ha valore NULL. Quindi in generale ti conviene tenere le immagini nelle stesse tabelle dei prodotti, in modo da evitare l'overhead (sia in termini di memoria che in termini di costo dei join) dovuto alle chiavi esterne.

    Più che altro non capisco perché hai creato una tabella per ogni categoria di prodotti.
  • Re: Tabella separata per immagini o campo img in tabella ?

    Giustissimo.
    Pensavo di utilizzare MySql, che un po' conosco, e avvalermi di MySqlworkbench che penso mi possa aiutare nelle relazioni.
    Per quanto riguarda le tabelle, non ho ancora stabilito: per me potrebbero andare bene Materiale1, Materiale2, etc., per i prodotti, e TabImg per le immagini. Per i prodotti ho la necessità di indicare una marea di caratteristiche con altrettanti campi che sono riuscito a limitare raggruppandoli. Ma il mio problema non è questo. Quello che m'interessa è il ragionamento alla base del collegamento che dovrò fare tra le tabelle prodotti e le immagini e capire se sia una buona soluzione utilizzare un'unica tabella per le immagini oppure no.
  • Re: Tabella separata per immagini o campo img in tabella ?

    kokkobil ha scritto:


    per me potrebbero andare bene Materiale1, Materiale2, etc.,

    kokkobil ha scritto:


    Quello che m'interessa è il ragionamento alla base del collegamento che dovrò fare tra le tabelle prodotti e le immagini e capire se sia una buona soluzione utilizzare un'unica tabella per le immagini oppure no.
    A me sembra ci sia qualche contraddizione di fondo.
    Materiale1, Materiale2...dovrebbero andare in un'unica tabella Materiali.
    Che io sappia le immagini non conviene mai includerle direttamente nel database, piuttosto meglio avere una cartella e richiamarle con opportuni comandi previsti dal software stesso.
  • Re: Tabella separata per immagini o campo img in tabella ?

    OsvaldoLaviosa ha scritto:


    A me sembra ci sia qualche contraddizione di fondo.
    Materiale1, Materiale2...dovrebbero andare in un'unica tabella Materiali.
    Infatti, non capisco questa cosa.
    Che io sappia le immagini non conviene mai includerle direttamente nel database, piuttosto meglio avere una cartella e richiamarle con opportuni comandi previsti dal software stesso.
    E' molto discutibile. Se le includi nel db hai comunque a disposizione tutte le utilities fornite dal dbms (in particolare, la gestione dell'affidabilità), oltre al fatto che dopo aver selezionato l'indirizzo nel db devi accedere al file system per recuperare l'immagine. L'importante è scrivere con cura le query per evitare di coinvolgere le immagini in operazioni nelle quali non sono necessarie.
  • Re: Tabella separata per immagini o campo img in tabella ?

    Grazie dvaosta, è proprio quello che cercavo.
    Quindi, riepilogando, inserendo le immagini in una sola tabella si "rischia l'overhead" e una minore velocità "dovuta alle chiavi esterne" quindi meglio allocare le immagini nella stessa tabella.
    Bene, ma se proprio volessi creare una tabella apposita, come collegare le immagini a quella data categoria ? Nella tabella delle immagini dovrei creare due nuovi campi: il primo, che riporta l'indice della tabella di appartenenza e il secondo che riporta una sigla indicante la tabella di appartenenza. Giusto ? Ma quanto mi costano le join ?
    Grazie
  • Re: Tabella separata per immagini o campo img in tabella ?

    Dovresti usare le table function, tipo
    
    SELECT blablabla
    FROM materiale1, (SELECT * FROM immagini WHERE tipo_materiale='materiale1')
    WHERE condizioni di join ecc.
    
    Il che rende il join ancora più costoso, perché prima devi fare quella select includendo anche tutte le immagini.

    Forse si può ottimizzare leggermente selezionando solo le chiavi delle immagini, per poi fare un secondo join a valle del primo per recuperare solo le immagini necessarie. Comuque sarebbe molto complesso valutare il miglioramento delle performance.

    In definitiva, fai quantomeno una singola tabella con tutti i materiali. Poi se in quella tabella metti anche le immagini è meglio.

    P.S.: in questo caso, la differenza nel tempo di esecuzione della query nelle varie situazioni non è di centesimi di secondo. A seconda delle cardinalità in ballo possono esserci differenze di secondi o minuti (volendo anche ore, ma suppongo che il tuo db non sia così grande).
  • Re: Tabella separata per immagini o campo img in tabella ?

    dvaosta ha scritto:


    E' molto discutibile. Se le includi nel db hai comunque a disposizione tutte le utilities fornite dal dbms (in particolare, la gestione dell'affidabilità), oltre al fatto che dopo aver selezionato l'indirizzo nel db devi accedere al file system per recuperare l'immagine. L'importante è scrivere con cura le query per evitare di coinvolgere le immagini in operazioni nelle quali non sono necessarie.
    Non è proprio così.
    C'è il rischio concreto di superare la dimensione del "pacco regalo" mysql.
    Rende pressochè impossibile il backup.
    Rende lentissimo il restore etc.
    Memorizzare le immagini dentro blob va bene se son poche e piccole. Volerci infilare dentro migliaia di foto di qualche megabyte non è consigliabile affatto.
  • Re: Tabella separata per immagini o campo img in tabella ?

    kokkobil ha scritto:


    Ma quanto mi costano le join ?
    Grazie
    Pochissimo, quasi niente, se la selettività è elevata.
    Il costo è in scrittura, non in lettura, per l'aggiornamento degli indici (e soprattutto gli eventuali lock veri o finti al commit delle transazioni).
    Join è bene se lo sai usare bene.
    I rapporti 1<>1 con campi indicizzati non creano problemi in lettura, dipende dal mix del workload.
    Supponendo che avrai poche scritture e tante letture, del join in questo caso non mi preoccuperei.
  • Re: Tabella separata per immagini o campo img in tabella ?

    +m+ ha scritto:


    dvaosta ha scritto:


    E' molto discutibile. Se le includi nel db hai comunque a disposizione tutte le utilities fornite dal dbms (in particolare, la gestione dell'affidabilità), oltre al fatto che dopo aver selezionato l'indirizzo nel db devi accedere al file system per recuperare l'immagine. L'importante è scrivere con cura le query per evitare di coinvolgere le immagini in operazioni nelle quali non sono necessarie.
    Non è proprio così.
    C'è il rischio concreto di superare la dimensione del "pacco regalo" mysql.
    Rende pressochè impossibile il backup.
    Rende lentissimo il restore etc.
    Memorizzare le immagini dentro blob va bene se son poche e piccole. Volerci infilare dentro migliaia di foto di qualche megabyte non è consigliabile affatto.
    Il backup può essere effettuato incrementalmente, il restore viene fatto una tantum per cui può anche impiegare ore. Quanto al pacco regalo, spiegati meglio.
  • Re: Tabella separata per immagini o campo img in tabella ?

    +m+ ha scritto:


    kokkobil ha scritto:


    Ma quanto mi costano le join ?
    Grazie
    Pochissimo, quasi niente, se la selettività è elevata.
    Il costo è in scrittura, non in lettura, per l'aggiornamento degli indici (e soprattutto gli eventuali lock veri o finti al commit delle transazioni).
    Join è bene se lo sai usare bene.
    I rapporti 1<>1 con campi indicizzati non creano problemi in lettura, dipende dal mix del workload.
    Supponendo che avrai poche scritture e tante letture, del join in questo caso non mi preoccuperei.
    Sono d'accordo se parti dal presupposto del tuo post precedente, ovvero che non memorizzi le immagini nel db. Se invece lo fai, Il risultato della join, nel caso includa le immagini, potrebbe facilmente eccedere la dimensione del buffer.
  • Re: Tabella separata per immagini o campo img in tabella ?

    Esiste un motivo TECNICO che puoi spiegarci per cui vuoi/devi inserire le Immagini come BLOB nel Database e non predisporre una Cartella o una struttura di Cartelle adatta a contenere le Immagini , e nel tuo Applicativo registri SOLO il Percorso Relativo o Assoluto a seconda...?
    Poi le Immagini le puoi caricare RUNTIME con qualsiasi Client tu stia lavorando...
  • Re: Tabella separata per immagini o campo img in tabella ?

    Salve a tutti
    grazie per tutte le risposte che mi stanno aiutando molto a chiarire i miei dubbi.
    Ad Alex rispondo che non c'è un vero motivo tecnico per cui debba inserire necessariamente le immagini nel database piuttosto che in cartelle separate. Cerco solo una soluzione che non mi dia problemi nella ricerca che desidererei molto veloce.
    Per intenderci, mi piacerebbe molto disporre delle immagini così come avviene per il famoso social "f" e in particolare che presenti le più recenti per poi caricare le più vecchie scorrendo la timeline.
    Se in proposito qualcuno può suggerirmi siti, notizie o pagine web simili gliene sarò grato.
Devi accedere o registrarti per scrivere nel forum
16 risposte