Don’t get me wrong, you can and you should. My main point is that you probably should not go for a singular God field.
Consider these sum types (expressed as Rust enums):
enum SocialNetwork {
GitHub,
GitLab,
BitBucket,
LinkedIn,
// ...
}
enum UserProfile {
NormalUser {
first_name: String,
last_name: String,
email: String
},
SocialNetworkUser {
profile_id: String,
social_network: SocialNetwork
}
}
I’d advocate for you to have two DB fields: type and content, whereas type would be "normal_user" or "social_network_user" and contents – everything else.
What I was trying – unsuccessfully – to convey to you is to separate at least types and contents, multiple times if necessary. You already mentioned these types of data will be in flux for a while so maybe a singular God field is the best option and you should just focus on app-level validation. Up to you. Maintainability should be the first priority.
