Per rispondere alla tua domanda, ci sono diversi aspetti a cui pensare.
A seconda di come vedi user , user -Information può essere modellata come parte di userprofile o viceversa:
user = {
"lastname": "Doe",
"firstname": "John",
"id": "a972f435-5263-401a-a03b-950e9e0e29c1",
"birthday": "1970-01-01"
}
Non c'è niente di sbagliato in questo tipo di dati. Se utilizzi un backend in grado di gestire JSON, puoi memorizzarlo subito.
D'altra parte, a seconda di quanto dettagliato è il tuo user , ha senso separare user -data da profile -data; o forse hai bisogno di utilizzare database diversi per scopi diversi: ad esempio, hai un login -servizio che serve l'unico scopo a log in utenti: in tale scenario ha perfettamente senso avere il tuo user in un posto e profile in un altro (forse stai usando MongoDB o qualcosa del genere).
Is this a sensible choice to make?
Non esiste una soluzione generale a questo. È una domanda filosofica piuttosto senza contesto. Un bel argomento per una discussione scolastica sull'architettura.
Would there be any security reasons in this style of architecture?
Purtroppo non sono un esperto di sicurezza per darti una risposta dettagliata a questo. Devi comunque proteggere il tuo sistema. Dal punto di vista della sicurezza, potrebbe avere senso dividere tra user e profile o superiore: user , profile , creditcard -data in tre diversi database. Ma questa è un'ipotesi ingenua. Ci sono persone che sono più sicure di me;)
Would this violate the concept of modelling an entity as a single class? (and are there instances where this is acceptable/expected?)
Are there any common patterns or best practices for modelling an entity in this way?
Come detto sopra: ci sono ragioni per gestirlo in un modo o nell'altro. Vorrei andare con finché non hai motivo di dividere realmente i dati, tenerli tutti insieme . Cerca soluzioni semplici in primo luogo e evolvi il tuo sistema insieme alle tue esigenze.