Why would I want to beat a developer with a manual just because he writes a non-relational table definition? T-SQL is not a relational calculus, it has many non-relational extensions. SQL Server is not restricted to supporting purely relational databases, it supports non-relational constructs too. Situations in which it is useful to go non-relational (Steve's example of staging data imports is a good one) are not unusual. That's why I say that I agree with Hugo that such things are not acceptable in a relational database; but at the same time I believe that they are nevertheless acceptable in SQL Server and are actually rather useful, because some of the time I'm not terribly concerned about being relational. It's a bit like believing that the only sane semantcis for functional programming languages is lazy at the same time as requiring the language to have syntax that allows one to specify that some arguments of some functions have to be treated eagerly instead of lazily (just try to find a sane way to build a database - relational or not - in a functional language without eager constructs - it is of course possible, provided you (a) have unlimited storage capacity and (b) don't care how slow anything is, but I've never met either of those happy circumstances).