I *MOSTLY* agree with what everyone has said about showing this to the DBA's or your manager, but it would sound like some aren't quite listening to you or have read between the lines... I am in the same position that a lot of the posters are probably in: I am the lead programmer and the DBA for our organization, so I do not have the issues you are having. I will also say nothing chaps my hide more than looking at the SQL database some third party has developed and seeing things like CHAR(1) fields used for something that boolean should have been used for, so that isn't the issue. However, from the sounds of it, bumping heads with this DBA will more than likely result in things being made worse, to the point that his requirements will be totally assinine just to be spiteful or to push his weight around. All of your arguements are valid as far as the problems this will cause, and the answers here (especially about bit versus byte and being able to have 7 more bit fields in a table for the same cost as one) are very good, so I would hope that maybe in your company there is another DBA or DBA assistant you can approach that may have the ear of the DBA in question to point out your arguements. Only if you can't do that, or it fails would i go above his head. As far as links, in this case MSDN would have plenty of links on the memory usage of different data types, and look at best practices on MS website as well. Also, you might find something in patterns and practices from Microsoft. Hope this helps Cosmo