simple database problem

Out of context: Reply #4

• Started
• Last post
• 4 Responses

• CAJTBr0

  thanks for the responses.

  all of the methods do work. i just wanted to check to see if there was some better method out there that i didn't know about, and from the replies so far i guess not.

  regarding the intermediary table method. yes, with just three tables it is a simple structure. but in some circumstances, it just feels like it gets over-complex for the simplicity of the task. eg, i want to catalog a set of photos in a database:

  i have a photograph which i've taken. taking up the foreground is a clump of mushrooms, then a landscape scene, leading to mountains in the background. i used a polarizer and a nd grad filter. i used a tripod, some flash on the mushrooms, a remote switch and had the mirror locked up. it was a commercial shot for a magazine, a calender and a photo library.

  in order to make a db that could handle this i need:

  a 'photo' table

  then something like the following tables-

  type: still life, portrait, architecture, nature

  location: landscape, industrial, indoor, mountains

  filters: polarizer, nd grad, nd, red

  extras: flash, tripod, reflector, remote switch, mirror lock

  purpose: personal, magazine, photo library, calender

  this photo would come under: still life, nature, landscape, mountains, polarizer, nd grad, etc. etc.

  so including the intermediates, i now have the following tables:

  photo
  type
  location
  filters
  extras
  purpose
  photo_type
  photo_location
  photo_filters
  photo_extras
  photo_purpose

  it's just an example problem, but doesn't all of that (and all the extra coding/thought that goes along with administering that) seem like too much for such a simple task?

  CAJTBr 0Permalink

  UpvoteDownvote

  Flag

  Show [[ numHiddenNotes ]] more notesAdd Note

  SaveCancel

View thread