Ikke i sagens natur, men hvis du har store BLOB'er, der tilstopper dine borde og hukommelsescache, vil det helt sikkert resultere i et præstationshit.
Ja, det er en almindelig tilgang. Du ville normalt gøre noget som f.eks. at have mapper opkaldt efter hver tabel, de er knyttet til, og som kun indeholder filnavne baseret på den primære nøgle (ideelt set et heltal; bestemt aldrig noget, der er indsendt af brugeren).
Er dette en bedre idé? Det kommer an på. Der er fordele ved implementering og enkelhed ved kun at have et enkelt datalager og ikke at skulle bekymre sig om at give webbrugeren skriveadgang til noget som helst. Hvis der måske kører flere kopier af appen (f.eks. aktiv-aktiv belastningsbalancering), så skal du synkronisere lageret, hvilket er meget nemmere med en database end med et filsystem.
Hvis du bruger filsystemet i stedet for en klat, er spørgsmålet så, får du webserveren til at betjene det ved at pege et alias på mappen?
- + er superhurtig
- + cacher godt
- - ekstra serverkonfiguration:virtuel mappe; har brug for passende filtypenavn for at returnere den ønskede
Content-Type - - ekstra serverkonfiguration:skal tilføje
Content-Disposition: attachment/X-Content-Type-Optionsheaders for at stoppe IE-sniffing efter HTML som en del af anti-XSS-foranstaltninger
eller serverer du filen manuelt ved at få et script på serversiden til at spytte den ud, da du skulle servere fra en MySQL-blob?
- - er potentielt langsom
- - kræver en del manuel If-Modified-Since og ETag-håndtering for at cache korrekt
- + kan bruge applikationens egne adgangskontrolmetoder
- + let at tilføje korrekte indholdstype- og indholdsdispositionsoverskrifter fra visningsscriptet
Dette er en afvejning, der ikke er ét globalt accepteret svar på.