Posted by J.O. Aho on 10/14/93 11:50

Frankly wrote:
> "J.O. Aho" <user@example.net> wrote in message
> news:4fb1eiF1hup8mU1@individual.net...
>> strawberry wrote:
>>
>>> I'm still not sure that the images bit is flexible enough, but I guess
>>> it's a start.
>> It depends on what would be stored there, if it's with full path to the
>> image, then it may or may not be enough, but if it's just the name of the
>> image (you can hardcode the path, so you don't need to save that in the
>> table), then many digital cameras uses 8.3 (12 character in total) as the
>> name for the image, in this case the 50 would be over kill, but then I
>> don't know what Frankly want to store.
>>
>>
>> //Aho
>
> I am thinking it would be better to hardcode the path. I tried to do the 2
> foreign key, primary key thing.

Should be

CREATE TABLE tablename( id1 INT, id2 INT, PRIMARY KEY(id1,id2));


> the camera does a IMG_166 for example.
> i normally leave what the camera does and add in Kitchen, bathroom ect.

In that case the varchar(50) makes more sense, maybe you can go down to say 30
or 40, this makes the database to become smaller.


> another choice might be a table
> with hardcode paths to the pictures and make a relation to the apartments
> table and if that works would i need a relation for the buildings table to
> show that picture.

You could make a relation table with ImageID, ApartmentID and BuildingID, this
way you don't have to make as many joins if you want to show pictures from all
apartments in a building. The ImageID could be the name of the picture.


//Aho

[Back to original message]