Tom van Hell schreef:Mijn grootse angst met dit soort programma's is dat je database corrupt kan raken en je duizenden bewerkingen kwijt bent
Voordat je het database bestand moet je dus altijd opletten of die nog werkt.
En hoeveel bestanden kan dat die database aan of is het verstandig om meerdere databases aan te maken per folder met afbeeldingen?
Het zal niet voor niks zijn dat professionals liever met CS werken met voor de raw bewerkingen een xmp bestandje per foto
Blijft gewoon veiliger mi
Die optie zit in Lightroom ook, die heb ik dus als eerste aangezet. Ik heb met LR2 al eens een corrupte catalogus gehad. Goh ik was toen blij met mijn XMP's.
Ik had wel een backup maar anders was ik het werk van die dag kwijtgeweest.
Qua wat het aan kan, ik lees dat er fotografen zijn die 50.000 tot 100.000 stuks in de catalogus hebben zitten. Bij anderen stopt het bij 5000 al (dat is wel erg weinig). Als ex-DBA heb ik wel wat verstand van databases, OS'en en filesystemen. De database die eronder zit zal niet het grote probleem zijn, dat is SQLite. In principe moet die makkelijk honderdduizenden records aankunnen. Op basis van wat ik lees (en weet in algemen IT termen) vermoed ik dat de snelheid wordt bepaald door een combinatie van:
1. Het aantal photos
2. Het aantal edits (waarschijnlijk slaat hij een aantal edits op in aparte records, dat kunnen dus meerdere per foto zijn).
3. Het feit of je wel of niet met .xmp's werkt (extra I/O naar de schijf).
4. Het aantal bestanden in een map
5. Je systeem.
6. De grootte (MB) van je fotos
Het aantal foto's in de catalogus op zich zal niet het grote probleem zijn. SQLite kan makkelijk honderdduizenden records aan (onder wat voorbehouden natuurlijk). Zelfs als die DB in een bestand zit is dat op zich niet eens zoveel voor een DB. Afhankelijk van hoe ze het in die database zetten (daar moet ik nog eens naar kijken) kan het aantal records wel groot worden als ze voor elke edit een aparte record hebben, maar dat verwacht ik niet (of in ieder geval niet voor alle afzonderlijke edits).
Als je met XMP's werkt zal denk ik alleen wat vertraging opleveren bij het schrijven van batches. XMP's zijn dusdanig klein en het formatteren ervan ook dat dat voor 1 file verwaarloosbaar is. Doe je er een paar honderd dan zal er wel wat vertraging zijn, vooral beperkt door belasting van je systeem en snelheid van je schijven. Wat wel een rol kan spelen is het aantal bestanden in een directory. Hoewel ik in LR artikelen vaak de bewering zie 'lokatie van je foto doet er voor LR niet toe' (en dat is op zich ook zo), is het ook een feit dat er veel filesystemen zijn die traag worden als je een X aantal bestanden of meer in een folder/map stops. Vroeger had je dat al bij 1000 entries, tegenwoordig ligt die grens hoger. Maar er is altijd zo'n grens. Ga je er overheen dan wordt de boel ineens trager (waarom laat ik even in het midden). Als je dan ook sidecars gebruikt verdubbelt dat nogal snel. Er was iemand die al zijn foto's in 1 map had staan...
Maar de grootste beperking is waarschijnlijk toch wel het systeem en misschien de grootte van de foto, i.v.m. rendering etc.
Ik vermoed dan dus ook dat de meeste mensen die tegen beperkingen in LR aan lopen te maken hebben met een combinatie van deze factoren, primair performance van hun systeem, wel of geen sidecars (waarschijnlijk alleen relevant bij batch jobs) en formaat van de foto i.c.m. processing power. Ik denk dat LR en SQLite het op zich nl. prima aankunnen. Maar ik ga het wel zien, dit weekend even 20.000 foto's importeren.
