It may also be worth remembering that certain aspects of http based protocols (eg parts of webdav) and the clients that use them don't cope well with very wide structures.
I dont think that this limited to just http based filing systems. I watched someone trying to manipulate about 2k photos in a folder using Windows Explorer gui (on ntfs) and it was painfully slow. Obviously if the client/protocol can page or progressively load results and there is an index for each sort order required, then this concern is less of an issue. Ian On 25 Apr 2010, at 18:47, Janne Jalkanen wrote: > > I don't think this is a problem with JCR as such - it's just that Jackrabbit > is designed so that it performs better with deep structures rather than wide > structures. > > Other implementations may function differently. > > /Janne > > On Apr 25, 2010, at 04:35 , Christopher M. Logan wrote: > >> I subscribe to the jackrabbit mailing list and this response made me think.. >> Why?? Using a check sum to build a folder structure.?. Shouldn't the folder >> structure be understandable... If that is recommended... I really must have >> missed the purpose of jcr... >> ------Original Message------ >> From: Matt Meola >> To: [email protected] >> ReplyTo: [email protected] >> Subject: Re: novice question - photo gallery >> Sent: Apr 24, 2010 6:21 PM >> >> Michael Yin wrote: >>> I believe that a fairly flat structure is not the most efficient for >>> jackrabbit. Maybe use dates (month/year) or some other grouping to further >>> build the tree? >>> >>> -mike >>> >> Indeed, just about all the advice out there is "go deep" instead of "go >> wide". One possible way to do that would be to calculate, say, and MD5 >> checksum from the file (its name, or its contents, whatever), and take >> the pairs of digits and make each of those pairs a folder. >> >> Example: an image named "blub", gives an md5 hash of >> 455523d86a8a1ab7c7d33208fe0219e7, which would yield a folder structure of >> >> data/pictures/gallery/45/55/23/d8/6a/8a/1a/b7/c7/d3/32/08/fe/02/19/e7/original >> >> data/pictures/gallery/45/55/23/d8/6a/8a/1a/b7/c7/d3/32/08/fe/02/19/e7/1024x768 >> >> data/pictures/gallery/45/55/23/d8/6a/8a/1a/b7/c7/d3/32/08/fe/02/19/e7/64x64 >> ... >> >> You could take them in groups of three, or four, or you could only go so >> far with it (not using the entire checksum) -- whatever you like. >> Regardless, you ought to be able to get a reasonably balanced tree over >> time. >> >> Just my two cents... >> >> >> -- >> Matt Meola >> >> >> >> Sent via BlackBerry by AT&T >
