Richard, Carlos, Simcha and Nigel, Thank you all for your answers on this matter. When I read Simcha's mail, it hit me like a hammer! That was what I was looking for! BUT: I have to see, that this creates way to much overhead, as I have to use INNER JOIN instead of LEFT JOIN, or an equvalent subquery. I'm currently testing with temporary tables to filter the data before going into the real query. As this is not a real project, just me testing the pros and cons of speed versus flexibility of exactly this table structure, there is no need to restructure the tables. I use 30,000 images as sample data, 7 attributes each. What I have for the images is 3 tables. table picture pid(primary): the id of the picture uid(index): the user id, to whom the image belongs table picture_attribute aid(primary): the id of the attribute name(index): a name for that attribute e.g. fsize table picture_attrib_rel (unique over pid,aid - to avoid the same attribute twice pid(index): the picture, this row belongs to aid(index): the type of attribute this row describes val_int(NULL): a field for integer values | val_vc(NULL): a field for string values | my class decides wich of these value types to use, the other is NULL My class emulates a foreign_key behavior on aid between picture_attribute and picture_attrib_rel. THANK YOU ALL!! Regards, Jan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
