Either, they're are often no right or wrong answers. Personally I'd probably have separate tables, after all that's exactly what RDBMS's are meant to do assuming you have the right indexes / foreign keys set you shouldn't see any performance problems. That being said don't create tables for the sake of it.
For example I'd only go for separately tables if the data in "users_profiles" and "users_settings" needs to be a sorted that way. If a user can have multiple "profiles" or other users can share profile records. If the data is relational then store it relationally.
I also would think decoding and encoding JSON that you have stored in a text field could become tiresome so you might want to consider that some database systems support JSON natively as a datatype. https://dev.mysql.com/doc/refman/5.7/en/json.html so you might be able to fit that into your thinking.
Mongo might be good fit if you are trying to describe a "User" with various other bits of information such as settings, permissions, profiles etc and you're thinking an RDBMS isn't a good way to store your data.
A JSON-type array might work ok for this - but you are then responsible for updating the 'schema' in all the records yourself. Eg, you decide to add a 'fallback_email' field to rescue accounts - doing that in a plain SQL table is easy - doing it with a JSON column can be a bit more tricky. It's also a lot easier to set defaults and rules in your SQL than it is with JSON.
Might not be an issue for you - but it's worth considering I think :-)
@richwilliamson "For example I'd only go for separately tables if the data in "users_profiles" and "users_settings" needs to be a sorted that way. If a user can have multiple "profiles" or other users can share profile records. If the data is relational then store it relationally."
So you will not use hasOne() ? If one user has only one profile and settings you will use only one table even if settings in 10 fields ?
@ohffs "A JSON-type array might work ok for this - but you are then responsible for updating the 'schema' in all the records yourself"
Totally right, just for this i will forget this idea ...
@tiger Well that's not to say I don't use hasOne() because I do. I guess if the "one" has similar data that can be grouped it makes sense. So the "users_profile" record has several attributes it makes the "users" table easier to read if that data is stored separately in another table. However if the "users_profiles" only has 1-3 fields it's more complicated creating an additional table for that table. Again there isn't a right or wrong answer but the warming signs are normally a) my table a lot of columns and it's unmanageable or b) I've got that many tables I can't find anything. As long as you're somewhere in between and you and/or your team feel comfortable then you should be on the right track.
I'm of the opinion that if there is a value you need to store that is specific to one individual user, and that user will only ever have one value, that probably belongs in the user table. A certain level of 'denormalization' is good for performance, and separate tables simply to have separate tables cause needless joins to be necessary which, albeit small, decreases performance.
