Hi,

We have a database that is too normalized, and this normalization is adding
too much complexity to our code, so we are going to take all the tables that
are too normalized and join them into just one table.

But still we are thinking about how would be the best way to do that,
joining everything possible into one big and fat table, or leaving some
tables normalized.

One of the problems is the table users, our software design is based on an
entity called "Person", we treat everything as a person, for example:

A user is a person, a customer is a person, a company is a person...

So we normalized it in the database to refect this and have some tables that
complements the person table.. something like this:

Person
Customer inherits from Person
Company inherits from Person
User inherits from Person

But now we are joining them into just ONE big and fat table.

So what I wanna know is, what are the setbacks of leaving a lot of fields
with NULL values, for example:

One of our customers have more than 20K records in the Person table, but
just 5 of them are users, the table users have just 2 fields (Username and
Password), so is there a problem in leaving 20K records with username and
password NULL?

We are taking this aproach because the time we spend solving these design
problems in the code isn't worth the trouble of having a well organized and
normalized database, as everyone already knows, disk space isn't a problem
anymore.


Any opinion is welcome.

Thanks.

--
Fabio Gomes


[Non-text portions of this message have been removed]