Ukládání obrázků do SQL databáze
Ahoj,
pročítám si někým naprogramovaný projekt a zaujalo mě, že profilové obrázky uživatelů jsou spolu s jeho údaji uložené v databázi. Samozřejmě to není pro mě novinka, ale rád bych znal názor zkušenějších, jestli je lepší mít obrázky v databázi, nebo je lepší je mít v projektovém adresáři.
V případě uložení ve složce v adresáři projektu je nevýhoda postupné zvyšující se velikosti adresáře celého projektu a ještě navíc by se zvyšoval chaos v souborech.
Na druhou stranu když by se obrázky ukládaly do databáze, není to pro práci s databází příliš náročné? Taky mě nenapadá (jsem začátečník), jaká by byla src="cesta" k obrázku v html kódu.
Ještě se prý obrázky ukládají na jiný samostatný server. Tam je to v databázi, adresáři, nebo jak?
Který způsob ukládání je lepší a proč?
Díky.
Díky všem za odpovědi.
Nevím, jestli je databáze slušná, ale používám MySQL, na ní s Adminer (občas phpMyAdmin) a v php pracuju s databází přes PDO.
Trochu mimo téma. Chystám se na dokumentaci Nette a musím říct, že to vypadá opravdu dobře. Je Nette lepší než třeba Laravel nebo Zend? Prý je Laravel lehčí na naučení a Zend je dobrý na hodně velké projekty. Hodí se Nette na všechno?
Pocitej s tim, ze vetsina beznych hostingu (s cenou do 200 Kc/mesic) ma na databaze limit casto pouze v radu par stovek MB. V radech GB uz to vetsinou nejde, nebo jen za priplatek. Takze o ukladani obrazku do DB nema moc smysl uvazovat (pokud jich nepotrebujes mit jen par stovek kusu a nepotrebujes ukladat originaly).
A navíc je pro řadu webů nutno mít obrázek připraven a uložen ve více rozlišeních (e-shop: malá šířka pro přehled výrobků a velká pro detail apod.).
Jedna věc je web, druhá věc je všechno ostatní.
Na webu generuješ stránku, obrázky se tahají na klienta, aby se vlastně zobrazily.
Ale když máš nějaký informační systém a chceš dělat reporty, neděláš je formou webových stránek, ale reportovacím nástrojem, který je schopný zobrazovat obrázky přímo z tabulky.
Prostě jestli obrázky v databázi nebo mimo záleží na konkrétním případu použití.
Na to abych mohl delat reporty v informacnim systemu, nemusim mit obrazky v databazi (coz je vetsinou uplne spatne z x duvodu)...
Mit to v databázi je v takovém případě naopak správně. Uveď mi prosím nějaké případy, kvůli kterým je to špatně.
Pominu důvod, kdy v případě, že to máš na disku v tisících souborech, tak je to neudržitelné a nepoužitelné pro reporty.
Staci uvest jeden - cteni nebo zapis z/do DB je vzdy pomalejsi nez na filesystem.
To uz nemluvim, o tom, ze kdyz das soubory do DB, tak jediny zpusob, jak se k nim dostat je pak pres aplikaci (data teda musi cestovat pres aplikacni vrstvy).
Pokud na reporty pouzijes neco normalniho (co ja vim treba iText), tak to vetsinou funguje tak, ze mas templatu v pdf s placeholdery a jenom doplnujes data. Klidne i obrazek, ale ten urcite nemusi byt v DB (v DB bude jen cesta, kde ho najit), muze byt vicemene kdekoliv (webserver, ftp, apod.).
Takže pro tebe je lepší, když musíš kromě jednoho přístupu řešit po síti sdílení složek, aby ses dostal k obrázkům? Každý report bude místo toho, aby dostal balík dat sahat a tahat jednotlivé soubory?
Jak to budeš řešit, když chceš report někomu poslat. To pak musíš myslet na to, že jej musíš vytvořit jinak?
A to nemluvím o správě složek s tisíci jednotlivými soubory (obrázky), jejich zálohování, údržbu, ...
Na úrovni databáze zajistíš referenční integritu jednoduše. Ty do toho namícháš nestandard, kdy budeš muset kontrolovat odkazy na soubory, hledat sirotky a naopak chybějící soubory.
Jak pak vyřešíš práva k jednotlivým souborům, protože někdo k určitým souborům mít právo bude mít a druhý ne. Složky s nastavenými právy?
Jak budeš řešit, kdy někdo bude mít přístup jen k určité sadě souborů v rámci složky?
Proč všechny větší Document management systémy neřeší ukládání jednotlivých dokumentů v souborech, ale přímo v databázi?
Na serveru kde se generuje report se slozi data z DB a obrazky. Nejak nechapu...
Kdyz ma report vystup v pdf, tak ho prece mohu poslat komukoliv. Zase nechapu...
O spravu slozek se stara aplikace (vytvareni, mazani). Zalohovani file serveru neni nic sloziteho.
Ano, referencni integrita je vyhoda v ulozeni v DB. Tu s filesystemem schopen zajistit nejsem, to vidim jako jedinou nevyhodu...
Pokud na obrazky maji pristup jen uzivatele aplikace, tak se tohle vsechno da resit na aplikacni urovni a je jedno jestli jsou obrazky v DB nebo na filesystemu...
A ktere napriklad? Z tech co znam ja, tak DB je vzdy pouzita jako uloziste metadat a binarni data jsou na filesystemu (Alfresco).
Reportovací nástroj je schopný brát bloby z DB a zobrazovat je rovnou. Ty budeš pracne skládat report z dat + souborů na disku, které si reportovací nástroj musí jednotlivě načítat jako soubory, aby je mohl zobrazit.
Můžeš, ale v případě, že bude mít zobrazování obrázků formou odkazů na externí zdroje, pak už to tak jednoduché není. O tom jsi psal, ne?
Z těch, co znám já je to zase naopak. Příklad třeba soudy. Tam jsou statisíce dokumentů. Pamatuju dobu, kdy to bylo na filesystému a následně se to převádělo do DB.
V nasem systemu mame servisu, ktera se stara o vygenerovani dokumentace k uveru. Potaha data z DB a prida obrazky z Document Management Systemu. Ten je in-house made, a taky si drzi data na FS a metadata v DB.
Report jsem bral jako nejaky vygenerovany dokument, ktery uz obsahuje vsechna data. Ne jen odkazy.
My prave prechazeli opacne, tada byly v primarni aplikacni databazi v BLOBu coz dost zvetsovalo DB (system bezi v Cine, spousty dat), dochazelo k lockovani tabulek pri zapisu (pri velkem loadu). Ted je to zmigrovane do DMS a pro binarni data musim pres REST. Nicmene primarni DB se o dost zmensila, pac ukladame jen idcko z DMS...
Uz se aspon nestava, ze externista napise select s hvezdickou a taha BLOBy, ktere vubec nepotrebuje a divi se, ze to je pomaly...
Tohle je spíš o návrhu databáze než o nutnosti mít dokumenty bokem na FS. Pokud počítáš s velkým počtem dokumentů, tak je neuložíš do tabulky s ostatními údaji, ale do samostatné tabulky. Pak záleží na tom, co ti SQL server umožňuje (partitions, komprimace dat apod.)
Moderní databáze ti umožňuje fulltext indexování uložených dokumentů a následné vyhledávání apod. Tohle s dokumenty bokem musíš řešit zase oklikou. A že DMS vyhledávání dle textu v dokumentech umožnit musí a to jen pro dokumenty, ke kterým máš právo se dostat.
Report není předvyplněný dokument, ale přehled spousty položek včetně obrázků - představ si to jako katalog.
Jinak souhlas, databáze s dokumenty/obrázky je velká. Pak jsou pro a proti:
1. soubory bokem = databáze je malá + mám desítky tisíc souborů na filesystému vs velká databáze. Na zálohování to vyjde nastejno - velké množství menších souborů se zálohuje pomalu. Stejně tak, jak zálohuješ změny, můžeš zálohovat změny i v DB nebo LOG. To je vlastnost zálohy DB.
2. pokud se změní úložiště dokumentů nebo musíš dokumenty nějak členit, musíš opravovat dotčené odkazy na externí
dokumenty v databázi. To je případ i když vytváříš cvičnou (testovací) verzi databáze. Se soubory v DB tohle neřešíš.