Autor Zpráva
WertriK
Profil
Zdravím všechny,
již nějakou dobu špekuluju nad tím, jak ukládat obrázky galerie - jde mi o strukturu uložení.
Ukládat všechny soubory ( fotka + náhled ) do jednoho adresáře se mi zdá jako nesmysl - kvůli procházení adresáře -> takže bych si pomocí php vytvářel nějaké podsložky a do nich fotky nahrával - ale podle jakého systému ty složky vytvářet ?
Napadlo mě vytvořit vždy novou složky, když bude předešlá obsahovat např 100 souborů nebo pro každý den kdy bylo něco uploadovány vytvořit novou složku.
První možnost se zdá být dobrá, ale bylo by nutné ošetřit aby smazáním fotek nezůstal nějaký adresář prázdný - tzn. kontrola zaplnění adresářů.
To druhé řešení má zase mouchu tu, že jeden den může někdo uploadovat 100fotek a druhý den jen jednu - tj. dva adresáře v jednom 200souborů a v druhém jen 2.

Popř. do toho ještě nějak zapojit mysql, ale moc mne nenapadá jak.

Uvítám jakékoli zkušenosti a nápady. Děkuji
Kcko
Profil
Werte ... nevidim zadnej problem v tom do toho zapojit DB ...
Vubec nespekuluj s hafo slozkama a prochazenim pres PHP ...

Podle me staci 1 adresar + DB
WertriK
Profil
Kcko
:)
Zapoměl jsem zmínit že, ke každému obrázku bude samozdřejmě v db záznam s názvem souboru a kategorií fotky.

Jde mi o to, že se může stát že bude v tom jednom adresáři např. 2000 souborů, čož se mi zdá docela dost - procházet takový adresář přes ftpklienta bude nepříjmené z důvodu nepřehlednosti a rychlosti načítání.
TSD
Profil *
Záleží na účelu.

Já třeba dělávám často galerie, kam klienti nahrávají fotky z akcí.
A řeším to tak, že klient zadá název série (třeba "Výlet na Šumavu"), já z toho pomocí php udělám 'vyletnasumavu', pak vytvořím složku, v ní složku '800' pro fotky a složku 'tn' pro náhledy.

Jak říkám, záleží na tom, jaká je v těch fotkách logická struktura.

Nedávno jsem tady četl o nějakém omezení 2000 souborů / složku (na ftp). Na to bys asi brzo narazil, pokud bys to udělal tak jak radí Kcko.
bukaj
Profil
WertriK
Já bych to udělal jednoduše. Budeš mít dvě složky. První, kde budou uloženy obrázky, které jsou již nahrány a uloženy v databázi. Do této složky by uživatel neměl lézt a cokoli v ní provádět. Jsou tam prostě jen uloženy objemná data (obrázky), protože skladovat je přimo v databázi bych označil za hřích. Pak budeš mít druhou složku, kam bude uživatel nahrávat obrázky přes FTP. A vždycky, když bude chtít, aby se zařadily do databáze, řekne aplikaci, aby prošla tuto složku. PHP složku projde, zkopíruje obrázek po obrázku do první složky, vytvoří u každého zmenšeninu, kterou uloží také do první složky, a zapíše údaje o obrázcích zkopírovaných do první složky do databáze.

Uživatel se vůbec nemusí zajímat o uložené obrázky. To jsou jen data, se kterými pracuje aplikace. Navíc, málokdo nahrává do galerie obrázek po obrázku. Většinou je nahrávání uskutečňováno po skupinách souvisejících obrázků (alb). Takže uživatel může specifikovat, do kterého alba se mají právě nahrávané obrázky z druhé složky zařadit (popř. jestli vytvořit nové a do toho je zařadit). Ale to všechno se již uskutečňuje v databázi. Ta první složka slouží pouze jako skladiště objemných dat a přes FTP by do ní uživatel neměl co lézt.
WertriK
Profil
TSD
Podobně jsem to dělal taky, ale jelikož si uživatel může udělat takřka jakoukoli virtuální strukturu galerie ( myslím hlavně větvení) a hlavně při úpravě fotografie je možnost ji přiřadit jiné kateogorii - což by bylo přesouvání souborů.
Snažím se právě práci se samotnýma souborama minimalizovat - protože to je, dle mě, jen zdroj různých chyb a nepříjmeností.

bukaj
Ano máš pravdu, tak nějak si to představuju, ale docela mě trápí pocit toho že při manipulaci s daty (s fotografií) dojde k chybě aplikace - uživatel bude mít možnost mazat celé větve adresářů a může nastat chyba - vyprší časový limit nebo něco podobného. Proto bych měl alespoň já takové zadní vrtáka abych to mohl ručně opravit. Samozdřejmě nebudu dělat galerii takovou, aby v ní byly chyby, ale člověk nikdy neví ...
TSD
Profil *
WertriK
Z toho co píšeš, vyplývá, že tvé použití galerie je jiné než o kterém píšu já.

Nepíšeš, jakým způsobem k fotkám přistupují uživatelé.

Když si představím, že bych řešil správu tisíců fotek, což je asi tvůj případ, tak bych asi vytvořil strukturu, kde by byla vždy složka pro rok, v ní složka pro měsíc a složka pro den.

A přístup uživatele k fotkám bych kompletně virtualizoval, tzn. uživatel by viděl jakoukoliv strukturu podle logiky věci a přesuny fotek mezi kategoriemi by znamenaly jen zápis do databáze, která by vypadala řekněme takto:

ID filename year month day group

nebo tak nějak
bukaj
Profil
WertriK
ale docela mě trápí pocit toho že při manipulaci s daty (s fotografií) dojde k chybě aplikace
V podstatě všechno děláš v databázi. Data uložená na disku jsou tam akorát, protože jsou binární, tudíž do databáze nevhodné. A každá slušná databáze podporuje transakce. Takže tepve poté, co COMMITuješ změny v databázi, sáhneš na disk a odstraníš data (soubory), které již nejsou potřeba. Pokud se něco pokazí mezi COMMITem databáze a výmazem souborů, uživateli to je docela jedno, protože aplikace pracuje s databází, ne soubory. Jediné, co mu může vadit je, že přebytečné soubory zabírají místo na disku. Teď by na řadu nastoupil nějaký garbage collector (nejspíš mark-and-sweep) pro ty soubory.
BetaCam
Profil
bukaj

To je v podstatě hezké, ale stejně by si měl udělat nejakou strukturu, protože už vidim rychlost procházení adresáře například s cca 200 - 300k obrázky. :) Nevim třeba sem jen spatně pochopil tvou myšlenku, ale proste mi to nepřijde zrovna jako optimální řešení. :)
aDAm
Profil
BetaCam
tak rychlost prochazení ti určí připojení k internetu. Ty dáš akorát povel aplikaci aby z DB vytáhla informace o další foto a aplikace ji pak zobrazí. Takže rychlost zobrazení je totožná jako když máš 2fotky v adr a nebo 1000fotek...
WertriK
Profil
Děkuji všem zůčastněným, asi to udělám jak píše bukaj - uvidíme co ukáže čas :)
aDAm
Profil
WertriK
tak ještě přidám já. Mám galerii a když zakládám nocou tak se vytvoří adr gallery-ID a tam se vali fota a do poadr TN zmenšeniny.
srigi
Profil
IMHO si urob repozitar s adresarmi podla cisla tyzdna. To dava max. 53 adresarov na jeden rok. Predpoklad je, ze za tyzden sa neuploaduje viac ako tych 2000 fotiek. Do db si pri uploade ulozis cestu a nazov suboru. To bude asi najjednoduchsie. Nevyhodou moze byt to obmedzenie.

Ine riesenie co ma napadlo, je pri uploade vygenerovat token. Vytvoris tak akusi upload session a subory v ramci tejto upload session ulozis do adresara "$token".
bukaj
Profil
BetaCam
protože už vidim rychlost procházení adresáře například s cca 200 - 300k obrázky
třeba sem jen spatně pochopil tvou myšlenku

Jak píše aDAm, všechno probíhá v databázi. Abych to zjednodušil (tzn. že takhle bych to takhle reálně asi nedělal), budou v tabulce fotkami, krom obvyklých sloupců jako název fotky, její popis, datum přidání, ještě sloupce fotka_soubor a nahled_soubor. A když uživatel bude přidávat foto, projde se složka, řekněme k_ulozeni (psal jsem o ní jako o "druhé složce"), kam uživatel přes FTP nahrál fotky. Ke každé fotce ve složce se vytvoří nový záznam v databázi, kde si uživatel zvolí název, popis atd., a skript zkopíruje fotku z adresáře k_ulozeni do adresáře, řekněme fotky_a_nahledy (o té jsem mluvil jako o "první složce"), fotku otevře, zmenší a zmenšeninu (nádhled) taky uloží do složky fotky_a_nahledy. Názvy souborů, pod kterými najdeme fotku a její náhled ve složce fotky_a_nahledy se uloží do sloupců fotka_soubor a nahled_soubor.

Takže například skript narazí ve složce k_nahrani na soubor fotka.jpg, do databáze vloží následující řádek:
nazev      | popis                  | ... další sloupce ... | fotka_soubor | nahled_soubor
Moje fotka | Tuhle fotku jsem vy... | ..................... | fotka.jpg    | fotka_nahled.jpg


A ve složce fotky_a_nahledy přibydou soubory fotka.jpg a fotka_nahled.jpg, kde první je akorát kopie toho ve složce k_nahrani a druhý je zmenšenina prvního.

Vysvětlil jsem to alespoň trochu? :)

Jediný případ, kdy by mohla být potřeba procházet složku fotky_a_nahledy je v případě, kdyby se podařilo vymazat řádky s fotkami z databáze, ale nepodařilo se odstranit soubory. Ty by tam pak zbytečně zabírali místo, protože žádná fotka by k nim nenáležela.

EDIT: Pokud by někoho napadlo, že by se tedy daly nejdřív vymazat soubory a poté teprve odstranit údaje z databáze, nedoporučuji. Může se podařit vymazat jeden soubor, ale druhý ne. V databázi fotka zůstane, ale např. k ní již nebudeme mít náhled. Je tedy lepší, když budou soubory na disku přebývat, než aby chyběly.

Vaše odpověď

Mohlo by se hodit

Odkud se sem odkazuje


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0