On 4/11/06, Gilbert Midonnet <[EMAIL PROTECTED]> wrote:
> I'm creating a database for a store. It will probably have several
> thousand items (but will probably never come close to 10,000).
>
> The pictures of the items will be stored in a file directory (not as a
> blob in a database). What is the maximum amount of files that can be
> stored in a directory and still have an efficient response time.

Efficient response time is very much a nebulous concept -- hardware,
load, and user-dependent.

As far as maximum amounts go, that is *filesystem* dependent.

Some MS specifics are here (eg 4+ billion files for NTFS)
http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/c13621675.mspx

Linux specifics vary all over the map, since there are so many
filesystems, some designed for closer to petabyte storage arrays.

> It would be so much simpler to have all the graphics in one directory.
> Will I be causing problems later on by doing that?

The smartest thing to do would be to abstract out the storage details
so you can change the implementation when you need to. You want a
function like PathToItem(itemId) that gives you back the location of
the file. But you want the implementation to be a black box to the
rest of the app. That way you can start with the simplest possible
approach and hard-code a path

function PathToItem(itemId)
  return '/path/to/my/file

pathToItem(8202) -> c:/wwwroot/myapp/images

Then later decide that you need to partition out numerically by the
item id into groups of 1000 as someone suggested in this thread

function PathToItem(itemId)
  return '/rootpath/' & (itemId DIV 1000) & '/' & itemId

pathToItem(8202) -> c:/wwwroot/myapp/images/8/8202

Then later you find that breaking the directories by month/year of
entry makes more sense

function PathToItem(itemId)
  return '/rootpath/' & Year(createddate) & '/' & Month(createddate) & itemId

pathToItem(8202) -> c:/wwwroot/myapp/images/2006/04/8202

etc.

If you use this to create the path when you write the image and when
you read it, you're set.

--
John Paul Ashenfelter
CTO/Transitionpoint
(blog) http://www.ashenfelter.com
(email) [EMAIL PROTECTED]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:237430
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Reply via email to