Question

I’m creating an Account table in my project’s database. Each account has A LOT of properties:

• login
• email
• password
• birthday
• country
• avatarUrl
• city
• etc.

Most of them are nullable. My question is, how should I design this in database?

Should it be one table with all those properties? Or maybe should I create two tables, like AccountSet, and AccountInfoSet, where I would store all those ‘advanced’ user’s settings? And last, but not least: if this should be two tables, what kind of relation should be between those tables?

Answer 1

If this is a relational database, then I definitely would not store those properties as fields in the Account table. Some reasons why:

1. Once your application goes to production (or maybe it’s already there), the schema maintenance will become a nightmare. You will absolutely add more properties and having to constantly touch that table in production will be painful.

2. You will most likely end up with orphaned fields. I’ve seen this many times where you’ll introduce a property and then stop using it, but it’s baked into your schema and you might be too scared to remove it.

3. Ideally you want to avoid having such sparse data in a table (lots of fields with lots of nulls).

My suggestion would be to do what you’re already thinking about and that’s to introduce a property table for Accounts. You called it AccountInfoSet.

The table should look like this:

AccountId int,
Property nvarchar(50),
Value nvarchar(50)

(Of course you’ll set the data types and sizes as you see fit.)

Then you’ll join to the AccountInfoSet table and maybe pivot on the “advanced” properties – turn the rows into columns with a query.

In .NET you can also write a stored procedure that returns two queries with one call and look at the tables in the DataSet object.

Or you could just make two separate calls. One for Account and one for the properties.

Lots of ways to get the information out, but make sure you don’t just add fields to Account if you’re using a relational database.