<br>
<blockquote><span class="q">&gt;Keep the images on the filesystem - out of a BLOB record.</span><br>
  <span class="q"></span><br>
  <span class="q"></span>Why?<br>
  <span class="q"></span><br>
  <span class="q">&gt;Map the filesystem, meta data and other stuff into the database.</span><br>
  <span class="q"></span><br>
  <span class="q"></span>Isn't there a limit to the number of files that can reside in one<br>
directory? If so, then how do you handle managing what is mapped<br>
where?<br>
  <br>
tedd<br>
</blockquote>
<span class="sg"><br></span><br>
<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Keith Richardson wrote:<br>You should organize the files into some sort of<br>nested directory tree. For ideas, examine the structure of the Postfix
<br>(mail server) queue.<br><br>
</blockquote></div><br>
If I was going to organise a camera watch like the one we are
discussing I would certainly go for the filesystem storage of the
pictures, keeping the pointers on a database.<br>
To circumvent filesystem limitations, if any because we are surely
talking about 640x480x72dpi pics taken every 10 seconds or so, and also
to allow me to do quick filesystem searches for an event, in case of a
never expected but always possible application failure, I would
organize my folders in a cascade like /year/month/day/hour/ kind of
thingh, so it would always be intuitive for both me and my successors,
and easy to tar the folders and send them to the PD, if ever necessary,
hehe.<br>
<br>
HTH<br clear="all"><br>-- <br>Alberto dos Santos<br>Consultor em TI<br>IT Consultant<br><br><a href="http://www.yournway.com">http://www.yournway.com</a><br>A internet  sua maneira.<br>The Internet your own way.