Online fly pattern database design (feedback requested)

http://www.montana-riverboats.com/Fliesdb/index.php


I'm finally getting around to building a fly pattern database.
This will be a public, queriable system that returns links
to remotely-located pages. That way I don't have to ask
people to upload images, and store tedious amounts of data
on my server........I can just make links to pages that
already exist somewhere else.
And then make a convenient way to find those pages.

Users will, in effect, be able to say:

"show me all the links to pages
where fly is a dry fly
and imitated_species is "mayfly"
and this here fly is an instance of "pmd"
and attribute "dun" is true
and attribute "parachute" is true

.....and then get a list of links.
The low-level database details are only
of interest to nerds. But I do need
feedback on the form.

What "attributes" are missing?
Plenty are (missing still).
I just thought I ought to get some feedback
at this point.

--
/* Sandy Pittendrigh --oO0
** http://montana-riverboats.com
*/

I would add Midge, Crab, and Shrimp to the "Imitated Species". I'd
change the "DryWet" thing to "Fly Type" and add Streamer, Sal****er,
Popper, etc. And maybe you could merge the "Fly Name" and "Instance
Of" categories.

Your own fly patterns are really nice, btw.

bruce h

Hi Sandy!

I would be very happy if there were an on-line pattern database
available. However, I do think that constructing a good one requires
quite a bit of work and upfront design.

On your entry form page you ask whether we would use such a
system. Speaking for myself, I think that the most important thing
that is missing is a more detailed pattern description. I _do_ need a
pattern database, but for my purposes, I should now what the fly is
built of: the materials.

The idea of storing the images of the flies elsewhere is tempting, but
I see that it could lead to a gradual degradation of your
database. The more patterns it would contain (the more time had passed
since its introduction), the more likely it would be that the oldest
images would no longer be available in their original locations.

So my suggestion is, assuming that you have the time and energy to
invest:
1. The database needs to contain many more attributes for each
fly. See http://www.fly-2000.net/ for an example.
2. All the data needs to be stored into the main database. You can put
a limit on the size of the image if disk space is a problem.

I hope this helped, although I'm afraid it didn't.

--
Jarmo Hurri

Commercial email countermeasures included in header email
address. Remove all garbage from header email address when replying,
or just use .

Jarmo Hurri wrote:
Hi Sandy!

I think that the most important thing
that is missing is a more detailed pattern description. I _do_ need a
pattern database, but for my purposes, I should now what the fly is
built of: the materials.

The idea of storing the images of the flies elsewhere is tempting, but
I see that it could lead to a gradual degradation of your
database. The more patterns it would contain (the more time had passed
since its introduction), the more likely it would be that the oldest
images would no longer be available in their original locations.



Good feedback Jarmo. Thank you.
More deatailed description?
Nothing to it. I'll add an optional field.
I will populate this database (mostly) with spidering
program. I'll point my program at various well-known, already
existing sites suck in the text portions of those sites.
This is technical stuff I don't want to get in here.
But I can populate the database with thousands of pages,
that I find robotically. I do this stuff for a living, and I'm
good at it. The robotic program won't be able to put fly recipies
into queriable format. If a recipie is on the page you'll be able
to see it by following the link, but, for robotically-loaded pages
you wouldn't be able to query on recipe attributes:
select all dry flies where wing_type='split-wing' and
fly.component.wing.material.type = 'calf tail' and
fly.component.wing.material.color='white'

....that would be nice, but that level of detail can only happen
when somebody laboriously enters the data with a form.
I'll add that stuff to the form I posted. So some data (entered by
hand) can have a zillion attributes. Other data, entered by robot,
will be more sparsely described.

RE dead links. It's easy to find those. I can write a little perl
program that loops through all urls in my database, twice a week,
and pings the page. If it comes back as "404 not found" the program
removes it from the database. There won't be any dead links.

If users have photos they want to share, they could upload them
to a public archive site (there are many) and then fill out a form
describing their own fly. The descriptive data will live on my server.
The image will live on one of the photo sites. For Urls (in the
database)
that point to images, rather than html pages that contain images,
I can write a program that dynamically generates a page, that shows
the remote image plus all the descriptive data found in the database.

Many people have a browser option turned on that only shows images
"from the originating site" so that last option (dynamic pages
generated
at my site that show an image at another site) won't always work
for everybody. But what the hell.

Like I said, I do this for a living. My job title is "database
researcher."
So I'm pretty confident I can make a hotrod fly pattern database,
for use by many. The query interface will be public.
Those who want to enter data will have to "register" first and get
a (free) password. All of this will take time.

But the beginnings of it are happening now.
Should be a queriable interface by Christmas (most development happens
between 9:00pm and 11:00pm).