Database Design Queries

[jasonpell]

Hi,

Before I say anything else, I just want to say how impressed I am with the polish of this application, its really nice.  However I do have some questions about the database design that I encountered while trying to move albums from one user to another (not important why, but its something I wanted to be able to do!)

I understand that albums are assigned a category
Pictures are included into an album

The category for albums of the form 1000*, associates ownership to a particular person for that album.  Now my question is,
why instead of this special logic to derive a category owner, why not actually insert these categories into the category table.  This
table has an owner_id -> thus we have an owner for the category, and these special 'User Galleries' categories, would have a
parent_id of '1' to put them under the special 'User Galleries' category.

I do not understand why the owner_id and owner_name are required at the picture level, because you can derive the owner_id
at runtime, from the ownership of the category that owns the album that owns the picture.

Wouldn't this simplify the structure just a little and make it easier to enhance and write extra functions for?

And if you want to have images in multiple galleries, even perhaps galleries owned by different people, then I guess you
would remove AID from pictures table and have a gallery_picture table, which would include AID and PID.

For now its not really that much of a concern, just wanted to understand some of the design decisions here, that
don't really conform to 3rd normal form database design.

Cheers
Jason

[Joachim Müller]

Coppermine has been founded as a "one-person-project" by Gregory Demar, who is now inactive and has handed development over to the current dev team. When building coppermine initially, he included code from other GPL applications, so the existing code is to some extent a legacy issue: we wouldn't want to make upgrade for users already using coppermine impossible, that's why we kept the db structure even if there could be better methods. We've been considering a complete redesign/rewrite of coppermine for the future (that's when a version number "2" will appear), but we have no schedule set up for it yet, only a very rough sketch.
I know this sounds like a poor excuse, but it isn't meant to be - I was instead trying to explain why the current structure exists. Of course it can (and should) be enhanced in the future.

Joachim