Question

Recently I had this discussion with some other developers about how too many columns in a table , or too many attributes on a model is a code smell . Some argue that a Model with too many Attribute is doing too many things , and should be split .
But what If the Model actually requires those attributes ?

Let me take the example of a users table .

A user can have
first_name , last_name , street_name , city , state , age , etc .
According to the argument , I assume street_name , city and state should be moved into a different table . I agree that related data are grouped together this way , but if the application is querying for the user with his address as well , wont that be a more expensive operation, since they’re in 2 tables now ?

So what is the right way to model tables with a lot of attributes ?
( Should we also consider these cases : when
1. the number of rows are going to be less
2. the number of rows are going to be huge )

Answer 1

Using your address scenario specifically, you’ll find it highly beneficial if your design is supposed to cater for multiple addresses per user or to track/trap multiple registrations using the same address.

Alternatively, you could consider a more generic address table implementation where you have a generic description field and a type column that tags the row as a specific type of address (e.g. email, house, office, spouse, etc.).

The moral of the story is the moral of this story is if there could be more than one of it, have a separate table. Over normalization only sets in when there’s no benefit in jumping the extra table or two for info that:

1. Doesn’t change much,
2. Doesn’t occur more than once or
3. Every primary key entity must have it.