Database Table Structure For Big And Scalable Applications

Iam a software engineer (since a few months ready with my study) and for my work i develop a large scalable web application. Another firm does the programming work and makes the d

Solution 1:

In my opinion this is bad for performance. Especially when the user count grows, is this true?

No.

There is a small difference in the insert/update cost which will not be dependent on the volume of data previously accumulated. Retrieval cost for a full record will be higher but slightly reduced for a partial record. At the end of the day, the performance differences are negligible as long as the record is still resolved in a single round trip to the DB (unlike a lot of trivial ORM implementations).

The biggest impact is functional. Its no effort to add, say, an attribute for title to the EAV table, but the normalized table may be knocked offline while the table is stresteched to accomodate the wider records (or the rows are migrated). OTOH you can't enforce a constraint at the database tier like every customer must have an email address.

Is this best or bad practice

Of itself neither. Although not documenting design decisions is bad practice.

far above 1.000.000 users in a few years

a million records is not a lot (unless the database design is really bad).