I do same also ;)

I use a child table with 3 field:
- PK of Person
- Username
- Password

For read you can create a view for this table.

At client edit:

I show Person.Name (and other Person fields), Username, Password and
buttons for select and edit Person.

eMeL

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