Can they? Yes. It's entirely possible to create the 1:0-1 relationship as you've demonstrated1.
But if you need that to be a 1-1 relationship, that breaks the relational model because the primary key of the child cannot be NULL
, yet it is entirely possible to have a transaction that only inserts into the parent table. So, you must use stored procedures for inserts/updates/delete so everything is handled as if it were a single logical entity and changes are made within a single transaction.
Should they? Depends. This is a physical (not logical) consideration and the only reasons you should do this are:
Performance - if the total size of the entity (in bytes) is large and a good portion of that data is read infrequently, it can improve performance to have the less-frequently accessed data in its own table to reduce the I/O for transactions that don't need to read that data.
Backups- if you need to have a different policy for certain data elements (or need to exclude them from backups entirely), you have some options if the data is stored in a separate table.
If there are security concerns around access, you could partition your data into separate tables and assign permissions that way, but you'd be able to achieve the same thing with views/stored procedures and denying direct access to the table.
1 I would question if HealthData
wasn't actually a series of measurements with the primary key being (UserId,Date)
or something similar.