5 dobrých důvodů, proč ukládat uživatelem nahrané soubory do databáze

Ještě před dvěma lety jsem se při myšlence ukládání uživatelských dat ošíval a argumentoval zvýšenou zátěží serveru (a tím pádem nižší rychlostí), popř. rovnou výpadkem databázového serveru a následnou nedostupností i obyčejných souborů ke stažení (linkovaných třeba i z cizích stránek). S přibývající praxí s klasickým ukládáním souborů do složek jsem však svůj názor na tuto problematiku dost zásadně přehodnotil, a výsledkem je, že počínaje dnešním dnem na Vyplňto.cz všichni uživatelé ukládají soubory pouze do databáze.

Proč tomu tak je a bude i u většiny mých dalších projektů se můžete dočíst v tomto článku, uvítám samozřejmě v diskusi Vaše názory na tuto problematiku.

Řízení přístupových práv

Při ukládání souborů do složek máme jen velmi omezené možnosti nastavení (omezení) přístupových práv. Má-li každý uživatel svou složku (ve které si může vytvářet podsložky), lze poměrně dobře zařídit, aby mohl každý zapisovat pouze do vlastní složky.

Poněkud složitější situace nastává, když chceme zajistit, aby mohli nahrávané soubory číst pouze někteří uživatelé. Necheme-li se zabývat dávno překonanou HTTP autentifikací, nevyhneme se ukládání souborů do tajných složek a jejich zobrazování např. pomocí PHP. Je to samozřejmě fungující alternativa, bohužel si však bere z obou přístupů to horší – je pomalejší než přímý přístup k souborům (přístupové údaje nakonec stejně asi budeme tahat z databáze) a v případě uhodnutí tajné složky zabezpečení mizí (leda že by se přes .htacces přímý přístup k souborům zablokoval).

V případě přímého uložení souboru do databáze je práce s přístupovými právy mnohem jednodušší - snadno si vylistujeme všechny soubory, ke kterým má kdo přístup, snadno operativně přístupová práva také odebereme. Pokud plánujeme soubory před zvěřejněním ještě ručně schvalovat, je databázové řešení také mnohem efektivnější.

Snazší programová manipulace se soubory

Pro přístup k souborům existuje (minimálně v php) jen velmi omezená sada funkcí. Věřím tomu, že rychlost stažení obsahu jednoho konkrétního souboru z databáze nebude při správně vytvořených indexech o mnoho pomalejší než stažení souboru uloženého na serveru ve složce. Na druhou stranu databáze umožňuje kouzla, která se v případě filesystému realizují jen velmi obtížně.

V databázi velmi snadno sestavíme SELECT pro získání seznamu souborů a snadno tento seznam seřadíme například podle názvu, velikosti nebo třeba počtu stažení. Pomocí jediného jednoduchého příkazu získáme také celkovou velikost všech uložených souborů, takže není problém hlídat přidělenou kvótu uživatele. Odpadají problémy s příkazy chmod a umask, php kód je jednodušší a mnohem přehlednější (odpadá rekurzivní procházení složek). K souborům můžeme přímo do databáze ukládat metadata (například popisky nebo rozměry fotografií). Měkký delete změnou atributu souboru je rovněž mnohem jednodušší než přejmenovávání souboru nebo přesun do složky v roli koše.

Samozřejmě je možné udržovat metadata v databázi a megabajty souborů mít uložené v adresářové struktuře. V takovém případě však musíme velmi obezřetně řešit otázky konzistence dat a veškeré operace jsou mnohem složitější – stačí, když klient přes FTP odmaže pár nepotřebných souborů, a data jsou rázem nekonzistentní. Nebo náhodou dojde na serveru ke změně přístupových práv k fyzickým souborům a přes administraci smažete pouze záznam v databázi (unlink skončí odepřením přístupu). O problémech při backupu ještě bude řeč.

Odpadá nutnost některých kontrol souborů

Zabezpečení mnoha aplikací zdaleka není takové, jaké bychom předpokládali (v praxi jsem byl zatím vždy spíš lehce šokován) – výjimkou není ani možnost nahrání libovolného php (perl,...) skriptu. Potom už stačí jenom tento soubor z webu vhodně vyvolat a vylistovat si například všechny soubory, zobrazit přístupová hesla do databáze a nakonec všechno třeba i smazat. Pokud pronajímáte nějaké řešení, hrozí teoreticky situace, kdy si klient takto celé stránky zkopíruje a posléze umístí (třeba s drobnou úpravou grafiky, aby to tak nebilo do očí) někam jinam. Podobná situace může nastat třeba i v případě, kdy na určitých stránkách pracuje mnoho lidí, a jeden z nich je z určitého důvodu propuštěn.

V případě ukládání souborů do databáze tyto problémy nehrozí – žádný z nahraných souborů není na straně serveru interpretován.

Snazší mazání (nepoužívaných) souborů

Je-li na serveru mnoho uživatelů, vznikají v případě ukládání souborů do složek dva problémy – množí se počet prázdných složek (ne každý uživatel možnosti nahrání souboru využije) a množství nepoužívaných nebo zkušebních souborů. Výjimkou není ani situace, kdy článek, jehož obsahem byl nějaký obrázek, byl smazán, zatímco soubor obrázku ve složce zůstal.

Při uložení souboru do databáze nejen že neexistuje problém prázdných složek, ale zároveň se přímo nabízí sledování přístupů k souborům (kolikrát a kdy naposled) a také refererů (zjistíme, na kterých stránkách by obrázek v případě smazání chyběl). Potom stačí již jen vytipované soubory měkce smazat a (pokud si nikdo nebude v určitém čase stěžovat) smazat nadobro.

V případě nedostatku místa můžeme také pomocí SQL příkazu vyhledat stejné soubory a ponechat je pouze v jedné kopii.

Snazší backup

Databáze poskytuje dobrý mechanismus pro zálohování a obnovu dat. Pokud budou všechna data uložena na jednom místě (tzn. soubory i metadata k nim v databázi), není zapotřebí řešit konzistenci a export - import bude možné provádět velmi rychle.

Shrnutí

V případě, kdy má na server nahrávat soubory více uživatelů, popř. kdy chceme řídit přístupy k jednotlivým souborům, stojíme prakticky vždy před rozhodnutím, zda ukládat úplně vše do databáze, nebo do databáze ukládat pouze metadata (název, popisek, tagy, velikost, čas přístupu,...).

Z hlediska zátěže již není zase tak velký rozdíl, zda má tabulka jeden nebo tisíc megabajtů – při správně definovaných indexech bude jistě časově nejnáročnější samotné připojení (x tisíc) uživatelů k databázi jako takové. Odměnou v případě uložení všeho do databáze bude zejména zahození starostí s řešením konzistence dat.