Databáze nebo soubor?

Pokud budeš chtít uložit tabulková data, jednoznačně tabulku v databázi.
Samotné obrázky se většinou do databáze neukládají - ukládaji se tam jenom jejich metadata a reference do filesystemu.

Když by byly v databázi, netrvalo by jejich načítání příliš dlouho? Co byste doporučovali?
S dobře nastavenými kešovacími hlavičkami ne.

A ještě bych měl dotaz na ukládání obrázků do tdatabáze
Dělá se to normálně - do sloupce typu *BLOB.

Co se s nimi bude dělat?

Jestli veškerá činnost s nimi bude vzít jeden nebo všechny a zobrazit, udělal bych soubory.
Pokud by se měly nělat nějaké výběry na základě jiných věcí v databázi a podobně, tak do databáze.

Další možnost je dát obrázek jako soubor a do databáze dát jeho cestu. To záleží spíš na praktičnosti a zamýšleném způsobu použití.

podle mne neexistuje rozumný důvod proč ukládat obrázky do databáze, až na vyjímku, se kterou jsem se setkal když by obrázky měli podléhat nějakému zabezpečení proti prohlížení, tedy i proti správci serveru, v jednom případě byli ukládány do databáze šifrované s časovou známkou v případě změny obrázku byl zneplatněn celý záznam, konkrétní detaily si nepamatuji, každopádně určitě do souboru

a v zálohování také nevidím problém? nebo ano?

matak
"i proti správci serveru"
Chiiiiiii, tak takovy program bych chtel videt :)
Pokud se v tom programu ma obrazek zobrazit, tak spravce serveru ma do programu pristup a umi si to heslo dohledat.
Pokud se obrazek zobrazi jen po zadani hesla, tak spravce serveru si muze nechat zaznamenavat komunikaci s danym programem, pripadne veskere operace a tudiz odchytavat vystup php kodu, pripadne hned ukladat do adresare stranku i s obrazkem. Presne tak, jak ji v damen okamziku vidis ty proti heslu.
Spis mi to prijde jako pokus o vtip zabranit spravci serveru v necem. Jedine takove reseni je, na/pres server nic, co nema videt, nenahravat/neposilat.

Ronny
Pokud se ma s obrazky pracovat casto, tak je jiste lepsi poslat primy soubor obrazku nez jej generovat z databaze.
Osobne se mi lepe pracuje na FTP s adresarem, nez generovat vystup z SQL. Pak budes chtit nahrat nejaky obrazek tam a zpet a bez scriptu ses nahranej akorat ty. Nebo se ti narusi databaze a muzes prijit o vsechny obrazky.
Dalsi neprijemny fakt je omezeni databaze na hostingu. Omezeni SQL dotazu.
Ale nekde mas treba 200MB pro databazi a pro web jen 50MB. Pak je prima vyuzit databaze.
Nekde maji rychlou databazi a s diskem pracuji pomalu, nemaji jej v Ramce, jak to byva u velmi rychlich hostingu. Tam se proste cas od casu zalohuje na disk, jinak je vse v pameti + samozrejme baterka pro pripad vypadku napeti, aby se to stihlo zazalohovat aspon.

Zalezi na tobe a podminkach.

obrazky se neměli zobrazovat, byla to databaze důkazních materiálů, program jsem nedělal ,detaily neznám a nešlo o program, ale o databázové řešení, obrázky byli šifrované v blobu, myslím že bezpečnostním opatřením právě bylo zjistit jestli obrázek někdo prohlížel do nějakého data to bylo to hlavní bezpečnostní opatření

správce serveru je možná špatně zvolené slovo, jak říkám detaily neznám, ale bylo to jediné vysvětlení, kdy jsem uznal důvod proč ukládat obrázky do dtb, jinak jak píšu prakticky v tom nevidím smysl

peta

Chiiiiiii, tak takovy program bych chtel videt :)
Pokud se v tom programu ma obrazek zobrazit, tak spravce serveru ma do programu pristup a umi si to heslo dohledat.
Ale, ale... správce serveru samozřejmě nemusí mít absolutní kontrolu nad daty a v takových citlivých aplikacích jako psal matak ani nesmí.
První věc jsou samozřejmě oprávnění, ale i tak... názorný příklad:
Adminům dám plný přístup na server i do databáze (už to je v citlivější aplikaci IMHO zásadní chyba).
Ukládání dat probíhá následovně: Uživatel vezme data, připojí časovou značku a pomocí svého soukromého klíče digitálně podepíše. Data se potom předají aplikaci a ta je uloží na server.
A teď mi řekněte, jak by admin mohl data zfalšovat. Jakýkoliv zásah do dat zneplatní digitální podpis a nový digitální podpis admin nevytvoří, protože nemá uživatelův soukromý klíč. Leda by použil svůj vlastní soukromý klíč, ale pak by bylo zřejmé, že data do databáze vložil on.

no tak to je přesně to co jsem chtěl říct :)

Joker
Tak jsem to myslel.
Pokud ty data se ukladaji primo sifrovane a uzivatel je nezobrazuje pomoci programu na serveru, tak s tim nejde nic.
Ale v okamziku, kdy pro zobrazeni/sifrovani pouzije program na serveru, tak je mozne s tim carovat jako spravce s pristupem.
Zkratka, pokud server odesila dekodovany obrazek uzivateli do nejake PHP aplikace, je to spatne.