> 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.
>

I must admit phrase "too normalized" sounds like "too rich" to me.
Sometimes people get religious about database design
(which is fairly often in software development), and I admit I am
often eager to accept that "religion", but I also find it is important
to know when to break the rules.
So, without giving you any advice, this is what I can say. If you know the
rules, you can break them, otherwise you are heading for a mess and
failed project.

> 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.
>

Have you ever heard of a term OTLT, which is an acronym for One True
Lookup Table? Google it up and think about it.

>
> 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?
>

20.000 rows in a table is not a problem for any database today, unless
you mess up the design, which you're doing.
That's simply wrong design if you ask me. I don't quite understand
what are the problems with normalized tables as you have mentioned,
but I am pretty sure those "problems" are much more solvable that having
everything stuffed into one single table.
Nulls are not problem per se, but you must know how to handle them and
you will have to handle them regardless of having everything in one table or
having clean normalized design.

> 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.
>

Yes, disk space is not a problem anymore, but not being able to distinguish
from Persons, Customers or Companies is.

Everything I said, of course is my opinion so caveat emptor, but I also
think
what I said here is what is generally considered as good practice.
I can not imagine what kind of complexity was added to you code because
of the database design, but I am sure it's nothing compared to problems you
are going to get if you go with one table design.
Just my 2 cents, take what you want and throw the rest away :)

Sasha