What is more efficient...

sidsel

On a picturepage up to 25 pictures can be displayed and I want to store filesize and length/width of the pictures in a table.

So what is more efficient?

Have 25 fields for filesize + 25 fields for length/width = 50 fields per row.
Store everthing as an "array" in a textfield ie. 100KB-1024x800:120KB-800x640: ... etc.

leatherback

Have a calc:

storage reuiqrements

You should however have one row per image, with a page-identification coluymn. This will greatly reduce your grey hairs when you decide you only want 10 pics per page..
Then I have the feeling that two tiny-int colums are more efficient
J.

AstroTeg

Originally posted by sidsel

2. Store everthing as an "array" in a textfield ie. 100KB-1024x800:120KB-800x640: ... etc.

Never ever store an array like this in a database. If you ever have the urge to do this, it means you have a table design problem. Like Leatherback said, setup a table to store 1 image per row with an additional table to store attributes of each image. Each image may have multiple attributes (or rows) in this second table. In terms of storage space, this method will be better than a text field. Plus, it'll be a ton easier and faster (for you and the database) to search and query the information.

sidsel

Speedwice the amount of rows does not matter?

In theory I can have up to 25 time more rows using the mentioned methods. Currently I have about 30000 images on the site and that would be 30000 rows 😕

leatherback

not really. Certainly not with 30 000 rows, and a direct query without difficult links to other tables etcetc

Sxooter

The rule of thumb for me is whether or not I'll ever want to treat the individual elements like individual elements WHILE they are in the database.

I.e. if you might want to select all the pictures that are smaller than a certain size, by a particular author, or in a certain catagory, then those things should be separate fields in the database. Whatever parts you'll never need to treat like parts until after it's out of the database, you can usually mush together.

The killer is when you THINK you want need them as individual elements, and then later on you do, and you have to rewire your application.

So make sure of your requirements of possible future requirements before you design your database schema.