Better database design approach to store thousands of users and their validations (composed by many attributes) about thousands of elements
Just looking at two aspects of the design:

First, it looks like you need a user table (to store information for each user of the site), and a film table (to store information about each film to be "validated", whatever that means).

From that point, you have a many-to-many relationship between users and films: each user can validate many films, and each film can be validated by many users.

This is normally handled by an intermediate table (a "mapping" or "bridge" table). This might be named something like user_film, and would have at least two or three columns:

user_film_id : integer, auto-incremented; primary key for this table
user_id : same type (and ideally, same name) as the primary key for the user table
film_id : same type (and ideally, same name) as the primary key for the film table


You can choose to simply use the user_id and film_id together as the primary key for user_film. Primary keys are generally used as a "clustered index", and the data is stored in the table based on that. Using a combined key means that each new entry could wind up anywhere in the table, making page splits and fragmentation much more likely. Using a "surrogate" key like an auto-incremented integer value means that each new record will go to the "end" of the table, saving time on inserts.

If you do use a surrogate key (as suggested), I'd put a unique index on user_id and film_id on the user_film table, to make sure that each user only has one entry for any given film.



Second, as far as the validations go, it sounds like a tagging system: you would have a number values that might help categorize the film (say, "color", "black&amp;white", "silent", "sci-fi", "horror", "romantic-comedy", "oscar", etc.)

If that's the case, then there are a couple of options, depending on your database.

One is a simplified version of what's called an "entity-attribute-value" model.

In your case, you'd have a validation table, with an ID value (again, I recommend an auto-incremented integer value) and validation name, plus any other columns (perhaps a description of what the validation is to be used for).

Then, you'd have a user_film_validation table, with the primary key from user_film and the ID value from validation, and an auto-incrementing integer (possibly a bigint or the equivalent) to be the primary key of user_film_validation (again, you could just use the first two values as the primary key here).

This makes it easy to modify the validation names: you just have to change one record to change "black&amp;white" to "B&amp;W", for example, instead of updating thousands of records. It also lets you add new validations without having to alter existing tables: simply adding one record to validation makes the new entry available to every user, on every movie.