null的意思是“不知道”或者“不确定”。如果真是有意为之，那么一定是非常专业的。试想一下，如果这是一个疏忽，对于那些没经过自己测试也没有经过大量用户使用的系统也许说得过去，对于经过了大量用考验的系统一定在各个地方已经包括了对null的逻辑的特别判断和处理了。
因此，对于一个用户比较多、使用超过1年的系统，可以说null值得存在应该算是一种比较专业的设计，而不是疏忽的结果。
举个例子，你写设计一个用户注册系统，其中你要求用户输入生日。用户可以不可以不输？如果他不输，就应该是null，如果你给一个所谓的“默认值”则非常不专业（当你的系统是多人开发时你如何让每一段程序都仔细地判断到底是所得到的默认值还是用户实际输入的值？）。
默认值固然省事，但是大多数时候显得很不科学，本来这个值是“不知道”或者“不确定”或者“不想输入”，你可以在界面上非常生硬地给出默认值，否则还可以很专业地允许空值。那种不在界面明确警告给用户已经给了默认值的做法，如果往往让挑剔的用户觉得很不友好。
往往最复杂、最八股的设计就是拼凑书本上一大堆的流行模式，但是没有经过经过许多不同的挑剔用户、比较长一段商业运营检验的软件。
越是大的系统，越向初学者的那种简单直观的设计风格回归。所不同的是简单的形式下面其实它对细节更加全面恰当地设计过了，他有了比较完善的技术从而可以自由地体现最初“头脑风暴”所想到的一切需求。反倒是“中间阶段”的不成熟设计，过分强调技术而不强调需求。
对于null，有着一整套计算逻辑。例如null值与非null值得简单计算得到结果还是null值，在统计中则忽略，等等。SQL Server7中的null不完全符合逻辑，经过讨论之后在SQL Server2000中根据“不知道、不确定、不关心”的应有的逻辑计算概念进行了一些改变。可见null是SQL Server数据库中一个有意义的知识点，而不是简单的东西。
大师举的例子并不恰当...用户体验是一回事，数据完整性又是一回事...
以楼主的例子而言，我实在看不出“会员类型”和“是否通过验证”有可null的必要...反而允许null会带来不必要的验证和程序的隐患...
我的做法，对text, image等大家伙就允许null，其他不允许
为NULL的我都默认为0
我不需要NULL值,以前好像看过一篇报告说的是NULL值影响SQL性能
我们设计系统时尽量不出现允许null值，用默认值代替之，如果有null值，则要进行特殊处理！