How to design my MySQL database? One or two tables?

Question

I need an advice from you.

I have users on my website who are allowed to upload 10 pictures. I want to give the users the opportunity to 1. order the pictures 2. give the pictures a title.

How should the database design look like?

I already have a table 'image_order' with the columns user_id first ... tenth

The values there are NULL or the image name. So the order works fine.

But now there is this second opportunity I want my users to give: a title.

I could easily crerate a new table 'image_titles' with the columns user_id image_name image_title

where user_id + image_name are the primary key.

But I don't know, if this is a good design. I also could delete the table 'image_order' and add column to my table 'image_titles' which could be named 'order_position'. So that there would be just one table 'image_titles' or maybe better 'image_properties' with the following columns: user_id image_name image_title order_position

where user_id + image_name are the primary key.

What do you advise? One or two tables? Or do you have another idea?

[It is about performance. There could be a lot of users and a lot of pictures...]

Answer 1

No. Creating a separate table for every field is not a good idea. Tables can hold multiple fields, take advantage of that. Currently you're designing your tables sideways, using columns as rows and tables as columns. Consider something like this instead:

Users
----------
ID
Username
etc.

UserImages
----------
ID
UserID
Title
SortOrder
etc.

Your object model has two entities, a User and a UserImage. Users contain multiple UserImages. So just create tables to reflect that model. In the above tables there is a many-to-one relationship, so any given User can have many UserImages and any given UserImage can have one User .

The logic to limit users to 10 images would then belong in the application, not in the database. You could put this logic in the database as application logic code in a stored procedure. Then perhaps revoke INSERT permissions on the table and require anybody inserting an image to use the stored procedure which contains that logic. (I'm making some assumptions about the database's permission model, hopefully this is possible.)

Either way, the storage schema shouldn't be broken to facilitate that logic. The schema should simply store the data, use code to implement the logic.

Answer 2

Proper database design principles generally don't smile on fixed size arrays in a row. You're often better off with a linked table, such as:

users:
    id, primary key
    any_other_details
pictures:
    id, primary key
    user_id, foreign key, references users(id)
    title
    picture
    any_other_details

This allows you to have an arbitrary number of pictures per user, and you just join the tables with a select if you need information from both.

Don't be too concerned about the performance of these joins, that's what databases are good at, and you can throw multi-million-row tables at them without issue provided it's set up well.

Answer 3

Most probably you want just a single table:

Table image
    user_id
    image_name // I assume this is some kind of link to the actual image file
    title
    ordering // an int in the range 1 to 10

pk: user_id + ordering

Your ten column image_order table is very unflexible (it has to change if the number of images per user changes) and also makes for complex queries, like the one needed to load all images for a user in the correct order