I don't quite understand the distinction you are drawing between an "image"
and an "image_attrib". To what real-world concept does "image_attrib"
correspond?
I'd suggest that the entities in your system are:
Image: with fields such as title and [film type stuff]
Comment: with a field for the comment text
ImageFile: with a field for the file location, as well as cached info from
the file itself, like its size or format
I'd set up a one-to-many relationship between images and comments, as well
as a one-to-many relationship between images and imagefiles (so that you can
provide the same image in many formats and sizes).
Where you put pricing information is primarily a matter of pricing policy.
If you have one policy for each image regardless of size or format (and the
actual price is a combination off this policy and the file they actually
choose) then you can just put in the image table, if the policy is entirely
dependent on the exact size and format you can put it in the file table, and
if it is some combination of the two you can put data in both tables.
(And I've tried to come up with some excuse for attempting a many-to-many
relationship between images and files, but can't get my head around a really
sensible system in which separate files for the same image might be included
separately in an entirely different image; I guess you could have a
'low-res' or 'jpeg only' version of the image, but I'd think it would make a
lot of sense to indirect the image table through a second 'filter' table
which performs the many-to-many than to just store redundant copies of the
image entries. Regardless, in this case you might have pricing specific to
the particular file, but you can no longer store it in the file table, so
now you'd have to relate the image (or this new 'filter' table) through yet
another pricing table with its own many-to-one relationship to the file
table, and that table would be used as the join table for the many-to-many
relationship.)
-rob
On 9/6/02 at 2:11 pm, Jason Soza <[EMAIL PROTECTED]> wrote:
> I think I'm in need of a little bit of database design guidance.
>
> I have a website that will be selling photos. I want to store all the
> information about the photo and any comments about it, and give a list of
> sizes it's available in, plus a price depending on which price scale the
> photo falls into, low, medium, or high. So far, I have 3 tables I'm
> confident in:
> |images|
> id MEDIUMINT NOT NULL PRIMARY KEY
> filename VARCHAR(50)
>
> |image_comments|
> image_id MEDIUMINT NOT NULL PRIMARY KEY
> comment TEXT
>
> |image_attrib|
> image_id MEDIUMINT NOT NULL PRIMARY KEY
> title VARCHAR(50)
> ....
> (bunch of film type stuff)
> ....
> price ENUM("L","M","H") NOT NULL
>
> Now, my problem is I don't know how to link a photo to a specific set of
> sizes it's available in (4x6, 5x7, 8x10, etc) AND link those sizes to a
> particular price scale.
>
> Sorry if this is more of a gen DB question instead of MySQL, but I'd
> appreciate any help.
>
> Jason Soza
>
>
> ---------------------------------------------------------------------
> Before posting, please check:
> http://www.mysql.com/manual.php (the manual)
> http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail <[EMAIL PROTECTED]>
> To unsubscribe, e-mail <[EMAIL PROTECTED]>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
>
>
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
