Ik wil een eenvoudige "foto-album" webapplicatie gaan schrijven, maar zit te twijfelen wat nou de beste manier is om de afbeeldingen op het filesystem op te slaan. Ik gebruik een SQL database om metadata op te slaan:
Niets bijzonders dus. Het enige dat misschien opvalt, is dat er geen veld is voor pad/url. Mijn idee was om het pad samen te stellen uit album.name en image.name. Daarnaast is er voor elke image een x-aantal versies, bv een thumbnail, het origineel en een (op bv 800*600) geresizede versie. Allen hebben dezelfde naam (image.name), maar staan in een aparte directory:
Op deze manier leg je geen banden aan het aantal mogelijke alternatieven voor wat in wezen hetzelfde plaatje is, en hoef je dus niet met een extra tabel voor urls te werken.
Zolang een album geen sub-albums heeft, lijkt dit me een prettig werkende oplossing. Maar wat nou als je een album2 hebt dat een sub-album is van album1. Is het dan mooier/beter om op het filesystem de volgende structuur te maken:
zodat de structuur op het filesystem overeenkomt met de in de database aangegeven genestheid, of laat je de parent-child relaties over aan de DB en 'mimic' je op het filesystem zo letterlijk mogelijk de databasetabellen:
en laat je de parent-child relaties tussen albums dus aan de db over.
Op deze laatste manier kun je in principe een album maken met de naam 'originals', hetgeen bij de eerste oplossing voor een naamgevingsconflict gaat zorgen. De eerste manier daarentegen is ergens wat intuitiever, omdat het een bijna letterlijke representatie op het filesystem is van de in de db gemaakte structuur. Bovendien kunnen meerdere sub-albums dezelfde naam hebben, wat bij de tweede manier niet kan. Wat zouden jullie doen, of zouden jullie het sowieso helemaal niet zo aanpakken?
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| album --------- id (PK) parent_id name title image --------- id(PK) album_id (FK album.id) name title description author pubdate moddate views ... |
Niets bijzonders dus. Het enige dat misschien opvalt, is dat er geen veld is voor pad/url. Mijn idee was om het pad samen te stellen uit album.name en image.name. Daarnaast is er voor elke image een x-aantal versies, bv een thumbnail, het origineel en een (op bv 800*600) geresizede versie. Allen hebben dezelfde naam (image.name), maar staan in een aparte directory:
code:
1
2
3
| album/thumbs/plaatje.jpg album/sized/plaatje.jpg album/originals/plaatje.jpg |
Op deze manier leg je geen banden aan het aantal mogelijke alternatieven voor wat in wezen hetzelfde plaatje is, en hoef je dus niet met een extra tabel voor urls te werken.
Zolang een album geen sub-albums heeft, lijkt dit me een prettig werkende oplossing. Maar wat nou als je een album2 hebt dat een sub-album is van album1. Is het dan mooier/beter om op het filesystem de volgende structuur te maken:
code:
1
2
3
4
5
6
| album1/thumbs album1/sized album1/originals album1/album2/thumbs album1/album2/sized album1/album2/originals |
zodat de structuur op het filesystem overeenkomt met de in de database aangegeven genestheid, of laat je de parent-child relaties over aan de DB en 'mimic' je op het filesystem zo letterlijk mogelijk de databasetabellen:
code:
1
2
3
4
5
6
| album1/thumbs album1/sized album1/originals album2/thumbs album2/sized album2/originals |
en laat je de parent-child relaties tussen albums dus aan de db over.
Op deze laatste manier kun je in principe een album maken met de naam 'originals', hetgeen bij de eerste oplossing voor een naamgevingsconflict gaat zorgen. De eerste manier daarentegen is ergens wat intuitiever, omdat het een bijna letterlijke representatie op het filesystem is van de in de db gemaakte structuur. Bovendien kunnen meerdere sub-albums dezelfde naam hebben, wat bij de tweede manier niet kan. Wat zouden jullie doen, of zouden jullie het sowieso helemaal niet zo aanpakken?
:strip_icc():strip_exif()/u/20300/icon_shrek.jpg?f=community){kind=icon}
