Quick question regarding database design;
Given I’m storing User data in a database, I can identify two (seemingly) separate forms of data associated with a user; account data, and profile data.
Most profile data is optional, and unnecessary (can, and often will be NULL) whereas the account data is integral to the user, and their ability to use the service (few or no records can/will be NULL)
Is there any advantage to splitting this into two tables as a 1-to-1? From merely a design perspective, it seems logical, but when talking performance is this a common (good) practice?
From a logical design perspective an entity type is defined by the attributes it has. Each unique set of attributes defines a different thing and should go in its own table unless you have a good reason to do otherwise. Use design principles like Normal Form and the Principle of Orthogonal Design to verify which attributes belong in which table.
The advantage of doing that is that you don’t need to create nulls or dummy values for attribute values which don’t exist. Using nulls in that way almost invitably leads to errors, ambiguous results and compromises later on.