I haven't given this any extensive thought, but the first concern I would have about this approach is that it would make updating an individual attribute a bit tricky.  Instead...

Nothing is wrong with it at all.  The three seperate tables (one for each type of code) is the proper approach.  Where some people go wrong is when they decide that...

Thanks for the feedback.  I do tend to get a bit sarcastic when I see ignorance masquerading as "elegance".  I must admit that I was frustrated at having to deal...

Joe,

I recall reading that article and it formed at least a part of my thinking on the matter, so thank you.  Actually, if I was to be completely honest about...

My mind if firmly locked when it comes to logical correctness and data integrity. (really these two things are just different sides of the same coin).  Besides openmindedness is overrated. ...

I appologize for the confusion.  I believe a careful reading of the article will make this very clear, but to summarize:

The three seperate tables, each with a single type of...

Thanks for the input.  This article went through a number of iterations and was reviewed by at least 5 different people for readability.  That's not to say that I couldn't...

I plead guilty to being a zealot.  I am absolutely a zealot when it comes to proper database design because I have to deal with the consequences of poor database design...

BTW I'm pretty impressed; a programmer who understands that the data model is the proper starting point of application design...  There aren't enough of you out there!

The "Attribute" or "name/value pair" solution is never a good solution partially for the reason you state but it goes further than that.  The real problem is that the domain...

That depends on the application design.  If it is to be a "Fat" client that can be used on a single workstation without network connectivity, then yes, each client would...

You might have just reignited one of the oldest debates in database design.  There are those who claim that natural keys are "fragile" and should always be avoided.  Then there...

Why not use MSDE, or MySQL or any number of other freely available DBMS's out there?  XML is NEVER the best choice for anything, at its best XML is an incredibly inefficient...

If your column is of the datetime data type the time element is always there, even if it is all zero's.  The issue you are having must be related to either...

I will first off tell you that I don't know the answer to your XML questions.  I know enough about XML to avoid it almost entirely.  It's barely an OK...