Creazione di una tabella separata per immagini o aggiunta di "campi immagine" a molte tabelle?

Prima di memorizzare i percorsi dei file:

• Avere più colonne del percorso dell'immagine (imagepath1, imagepath2 ... imagepathN) viola 1NF .
• L'archiviazione di più percorsi di immagine separati da virgole nella stessa colonna viola anche 1NF.
• Quando violerai la più semplice delle forme normali, avrai molti mal di testa in futuro.
• La cosa corretta da fare è creare una tabella separata per le immagini . Quella tabella avrebbe un FK con la tabella utente (userid). Quindi inserisci in quella tabella tanti percorsi di immagine che desideri per qualsiasi utente.

Riguardo alla memorizzazione di immagini reali come BLOBS .

• Si applicano le stesse regole su NF1. Si applica la stessa tabella separata per le immagini.
• In questo caso avere tabelle separate per BLOBS è buono perché il DBA può mettere le tabelle immagine in un tablespace separato, ottimizzando il disco IO .
• Anche nel caso in cui agli utenti sia concessa solo un'immagine, si consiglia la denormalizzazione creando una tabella separata con una relazione uno-a-uno.

Nota: non posso darti sintassi perché non ho familiarità con i tipi di dati MySQL.

Sono assolutamente d'accordo con user61852 sulla questione dei percorsi dei file, ma non posso essere in disaccordo abbastanza strongmente su BLOBS .

Sebbene la domanda non menzioni specificamente se si tratta di un'applicazione web o di un'applicazione client-server più tradizionale, sembra che stiamo parlando di un'app Web dal contesto fornito su USERS & PRODOTTI.

Se questo è il caso, allora non ci sono scuse per non usare un CDN, specialmente con incredibili CDN trasparenti come www.cloudflare.com . Ce ne sono altri, ma io amo CloudFlare e non posso raccomandarlo abbastanza. Suppongo sia più importante che tu usi un CDN rispetto a quello in particolare che preferisci ...

Memorizzare le immagini nel DB poiché BLOBS non è mai stato più veloce del file system a meno che non si abbia un hardware specializzato che si può sintonizzare a un livello molto basso per ottimizzare il file IO (e ci sono pochi esperti che ho incontrato su chi realmente fai questo meglio delle migliaia di ingegneri che lavorano su questo problema a livello di sistema operativo / driver).

Ancor peggio, usando DB BLOBS, non solo si preclude l'opzione CDN incredibilmente più veloce di distribuire geograficamente e di ospitare asset di immagini statiche (e CSS, e JS e font ...) il più vicino possibile ai visitatori del web, ma si finisce anche per rinunciare alla possibilità di utilizzare server web più veloci come nginx o sistemi di caching front-end come Varnish per servire le tue immagini (e CSS, JS, ecc ...) che è un peccato perché sono più veloci di apache e IIS se correttamente configurati.

Ovviamente, rinunciare anche alla possibilità di combinare nginx, vernice e CDN poiché non è possibile utilizzare i singoli componenti a meno che le risorse non siano archiviate nel file system.

Ho sviluppato alcune app che sono state implementate in ambienti cloud in cluster che hanno creato una sfida nella distribuzione delle risorse di file che erano necessarie per ogni server in un cluster. Inizialmente potresti essere tentato di considerare l'archiviazione delle risorse immagine nel DB come BLOB in modo che ogni nodo possa accedervi e quindi non devi preoccuparti di distribuire tali risorse ...

Evita questa tentazione. Ho scoperto che è meglio consentire ai file system, ai server Web, alle cache e alle CDN di fare ciò che fanno MEGLIO e lasciare che il DB faccia ciò che sa fare meglio. E questo sicuramente non memorizza le immagini e le serve rapidamente per le applicazioni web.