A Site for Photographers by Photographers

Community > Forums > photo.net > Other > The Ideal Photography...

The Ideal Photography Database

drew Fulton , Apr 16, 2002; 11:08 p.m.

Well, after many posts here trying to get some help with Access I have come up with a project that I am going to take on which will hopefully benefit everyone that is interested. I plan to create the "ideal cataloging database" using Microsoft Access 2000 (my choice of program is only because I already own it ). After this is developed I will release it to the public so anyone can use it free of charge. Anyone objects let me know

I plan on using John Shaw's cataloging system that is outlined in The Business of Nature Photography because it is simple enough for me to develop and easy enough for other people to expand. For those that don't know it consists of a large amount of categories that all have an abbreviation. Each category has a number starting at zero and counting up. You end up with unique codes such as M00001 (first slide in the Mammals category) and B01268 (1268th slide in the Birds category). This system is easy enough to use and to expand for each specific user.

That being said, here is where I need help from all of you guys. What exactly would you guys want the "ideal" database to do? What information do you all want to see included. Here is a screenshot from the one I threw together quickly. Don't worry about layout or anything, just look at the fields and let me know what others you would want to add. Any more informatoin about a certain slide would you like stored? How should I deal with dupes?

I also want the database to track submissions and editor information. I believe I will leave that for another discussion when I get to that stage. Thanks for the help. This will be my first large database programming experience and a learning one at that. Hopefully with all of your help this will make it easy for someone who is new to photography find a free and efficient way to categorize their slides.



    1   |   2   |   3   |   4   |   5   |   6     Next    Last

Nick G , Apr 17, 2002; 01:52 a.m.

Hmm...Microsoft Access. Not my first choice, Oracle would be my first bet (but of course since I have worked for them for over five years I am a little biased) IBM also has a viable solution.

Luke, please, please don't give into the dark side ;-) IBM and Oracle are better suited for large files in the database. Microsoft is always playing a terrible runner up.

Anyway, that is my two cents worth.

Javier F. Lago , Apr 17, 2002; 03:05 a.m.

Access is a good choice, because this database is not intended to be used in a fileserver and accessed by several people at a time. It'll be used from one PC at a time, so access is perfect for that.

what I recommend is to use Access as the database core, but the front end (the part you see) in Visual Basic. This gives a more stable and liable look, and it's almost the same as access alone to develope.

Victor Panlilio , Apr 17, 2002; 03:25 a.m.

Oracle? A bit expensive, don't you think, and overkill for this class of application? Unless you run a server farm, which most of us, unlike Philip, don't have at home. I have to ask Drew -- if this is a learning exercise, how about using open-source (and FREE) RDBMSes such as MySQL or PostgresQL or low-cost alternatives such as Valentina? I mean, c'mon! And come to think of it, this sort of thing can probably be built MUCH faster (probably less than 15 minutes) in FileMaker Pro, which is cross-platform (Windows as well as Macs -- w/c probably are preferred by more photographers anyway). Access is Windows-only.

Victor Panlilio , Apr 17, 2002; 03:39 a.m.

Access is NOT a good choice (too limiting)

Javier wrote: "Access is a good choice, because this database is not intended to be used in a fileserver and accessed by several people at a time. It'll be used from one PC at a time" -- One...PC...what about other platforms? Macs? Linux? -- Javier also wrote: "use Access as the database core, but the front end (the part you see) in Visual Basic" -- VB only produces executables for Windows. How about, if Drew is going to do it right for *everyone* on photo.net, maybe he tries something like Runtime Revolution, which has a FREE starter kit and supposedly produces Windows/Mac/UNIX apps from a single codebase? Write once, run everywhere? Just a thought. This is, after all, about the ideal photography database, not Make-Bill-Gates-Even-Wealthier-Than-He-Already-Is.

Jacob Wright , Apr 17, 2002; 04:23 a.m.

Drew, Sounds like a good project. My first comment on the "sample" you posted is that it seems like you're limiting it to wildlife photography. I might try and broaden it if I were going the "ideal photography database." For instance I would drop the "sex", and "latin name" heading to begin with. I also think that I would add spaces for copyright info, model releases, etc. I know you were talking about making this as a resource for begining photographers, but why not think big?

The other things that I would like to see in a general database, would be a wide variety of listing categories, an ability to expand the catagories, and also an ability to cross reference an image under multiple categories (i.e. a picture of a person in a canoe could be under listed under people, water, boats and sports for instance). This might mean changing the numbering system (the numbering system you mentioned assigned numbers by listing category, by allowing multiple listing you would need multiple numbers under your system as I see it). The numbering could be somewhat arbitrary it seems, since the purpose it serves is simply to allow the photo to be found once it's description has been pulled from the database.

Good luck on the project, drop me a line when you finish it.


Hubert Figuiere , Apr 17, 2002; 04:49 a.m.

I would personnally go with a free software path: MySQL as a database backend, and PHP + Apache as a web based frontend.

Another solution would be to use photo.net system that is based on ACS, but it seems to require Oracle RDBMS (really costly) and do much more than a simple photography database.

Shashvat Sinha , Apr 17, 2002; 05:35 a.m.

Crosslinks anyone?

My thought of an ideal database was like this:
1. Each photograph is stored in one main table. All the image info is stored alongside, e.g. aperture, shutter, ..., location, time, ..., description.
2. There are other tables, such as Wildlife, Travel, Architecture, ..., Glamour etc. which do not contain photographs.
They contain links to the photographs in the first table.
This way, a photograph of Big Ben in London will be linked from the Architecture as well as the Travel tables (as an example).
When adding a photograph to the database, you add it to the main table with all the information you have. Then you select checkboxes to associate the photograph with whichever other tables you want to associate it with.
As your photographic horizons expand, add more tables e.g. Erotica, Portraiture, Industrial.

Matthew Geddert , Apr 17, 2002; 05:56 a.m.

i think access is a fine choice for the majority of users... and since he already owns it and sounds like he is going to give his work to the world for free why argue?

I like what you have, but would also be interested in seeing the ability to tie shooting data to this system... for those of us with EOS 1V's, F5's, F100's etc... all of these systems store different data and my guess is that people may want to be able to improt this data directly from their software application. i only ahve experience with the eos 1v software package. it can save all your shooting data in CVS format and then it could easily be imported into access... here are a list of the fields it stores:

Film ID
Frame No.
Focal length
Max. aperture
Exposure compensation
Flash exposure compensation
Flash mode
Metering mode
Shooting mode
Film advance mode
AF mode	Bulb exposure time
Multiple exposure
Battery-loaded date
Battery-loaded time
Obviously other cameras will store other things... but if there woudl be an easy way to create a joined table that would join to this database filled with shooting data that can, but doesn't need to be used, i am sure some people would like that. Those people using Digital cameras and with digital images also have the ability to store most of this data... i can't really think of any other info that would be needed... except the film roll info (i.e. film type)

Allan Jamieson , Apr 17, 2002; 06:19 a.m.

Thinking from a landscape point of view, it would be useful to have searchable categories along the following lines, i.e. start with a country, then the general area, local name/s that are relevant, subjects included in image, which could include rivers, waterfalls, mountains, flowers, wildlife, people, sports, etc. Seasons could also be a useful search option as could details such as is the image landscape or portrait style.

Obvious things like film used, exposure details, filters ( if any ) that were used, even time of day if you really wanted to be precise. And for photographers using more than one camera system, you might like to know which camera and indeed even lens that you are taking most of your best pictures with.

I think, ideally a programme like this should be able to be adapted slightly by any users to suit their own specific needs, otherwise it might just become too big and unwieldy if you try to please everybody from the start.

    1   |   2   |   3   |   4   |   5   |   6     Next    Last

Back to top

Notify me of Responses