Simple database for photo gallery - need help

I'm trying to create a photo gallery for my website using PHP & MySQL.

However, I'm getting a little confused on how to set up my database.

Here's what I got so far:

============================================
Table 1: photos_image
-----------------------------

image_no - primary key
comment - text to accompany image
filename - filename of image
directory - links to which gallery image belongs to


Table 2: photos_gallery
-----------------------------
directory - primary key (Each gallery will be in separate folder)
gallery_name - name of gallery (User friendly name to display to user)
============================================

What I want it to do is when a user selects a certain gallery from a drop down list, a page will load up with the images of the associated directory name.

I have all the images listed in one table, (which would realistically contain more than 250 images - but still allowing for expansion so up to 10000), and would be searching through the image table, and matching the directory name for the gallery selected. Is this the most efficient way to do what I'm trying to do? {did i make any sense?}

or would it be better to have one table per gallery? - in this case is there a limit to the number of tables allowed per database?

Any better ideas?
Thanks

Access time (as measured by page reads) is a function of indexes. If you have a value in your where clause you should consider indexing it. I say CONSIDER because indexes have overhead associated with it on inserts, updates and deletes. However, if you are only retrieving rows, you should index all the columns that you are querying against (most databases support indexing multiple columns). You should consider indexing 'directory' so that you can show just those values for a gallery and image_no so you don't have to do a table scan once the user has selected a given image.

There is no benefit to putting the data in separate tables unless you do massive updates and deletes against only a single gallery (by massive, I am talking a minimum of a couple of thousand rows). I once built a database where I had multiple nearly identical data sources, but they would be updated independantly. I had one table for each data source so I could do a simple truncate and bcp for a given source and not have to deal with logging all those (millions of) transactions.

Your database sound like it is not potentially large enough to have performance issues, so just leave it in a single table and build the appropriate indexes.