问一个很关键很致命但却不一定难的问题。

Question

这个真没什么好说。
规则不能为null的那就从源头控制不能为null。
如果没有规定不能为null，那么用的地方自然要判断，这是必不可少的。

Answer 1

简单，你把所有的字段设置为非空的，并且设置一个默认值就不用验证从数据库里取的数据是不是null了

Answer 2

简单，你把所有的字段设置为非空的，并且设置一个默认值就不用验证从数据库里取的数据是不是null了
不一定的。如果有a表和b表，你关联a表和b表的时候，b表没有相应的记录，它就null。而且和上面问的一样，会不会增加存储空间，如果你全部设置了默认值。

Answer 3

dbhelper有问题 正常不存在空 

Answer 4

简单，你把所有的字段设置为非空的，并且设置一个默认值就不用验证从数据库里取的数据是不是null了
不一定的。如果有a表和b表，你关联a表和b表的时候，b表没有相应的记录，它就null。而且和上面问的一样，会不会增加存储空间，如果你全部设置了默认值。
？？？
这是 什么问题呢？关联不出记录关NULL什么事？最多查不出记录而已，返回表是空，你自然在程序中要去处理啊！

Answer 5

你要想过滤掉为null的记录，就直接加个条件：where xx is not null

Answer 6

if 字段名 == DBNull.Value

Answer 7

同意，代码中加入判断，显得可读性差了，但是稳定性回复了，至于数据库中是否要设置默认值，看你的业务需求了，有些情况下，在程序中可能就是要读取到null值呢，甚至要根据null值进行判断。
不能说多了判断，程序就不好了，你这算是一点小强迫

Answer 8

简单，你把所有的字段设置为非空的，并且设置一个默认值就不用验证从数据库里取的数据是不是null了
不一定的。如果有a表和b表，你关联a表和b表的时候，b表没有相应的记录，它就null。而且和上面问的一样，会不会增加存储空间，如果你全部设置了默认值。

你用 inner join就没Null，但是这样破坏了数据的完整性，Null是不可避免的

Answer 9

简单，你把所有的字段设置为非空的，并且设置一个默认值就不用验证从数据库里取的数据是不是null了
不一定的。如果有a表和b表，你关联a表和b表的时候，b表没有相应的记录，它就null。而且和上面问的一样，会不会增加存储空间，如果你全部设置了默认值。

你用 inner join就没Null，但是这样破坏了数据的完整性，Null是不可避免的打个比方说，A为主表，B为子表，A中有记录，但是B中用户没有填，这样你关联出来的数据中，Null是肯定会出现的，但是如果你用 inner join去消灭了Null，是不是条数变少了？数据完整性就是这个道理

Answer 10

这是一种不可避免的情况，这就好比你吃煮鸡蛋，不能因为你不吃蛋壳就要求母鸡生蛋的时候只生蛋清和蛋黄，你要做的就是在处理这个煮鸡蛋的时候加入一些方法，例如使用
this.煮鸡蛋.冲一下凉水（）；
这个方法，达到方便剥壳令用户满意的结果。

Answer 11

我一般是允许参数可以为Null，被调用函数内增加Null的处理

Answer 12

很多类型不要盲目地去ToString()就行了对于你说的DBNull.Value在类型转换时必须判断
用DataReader读取数据行，如果为空，reader[0].ToString()也不会报错的（空字符串）

Answer 13

我目前就是在sql 语句中用isnull来判断，但是就怕sql语句效率会很低。

Answer 14

同意，代码中加入判断，显得可读性差了，但是稳定性回复了，至于数据库中是否要设置默认值，看你的业务需求了，有些情况下，在程序中可能就是要读取到null值呢，甚至要根据null值进行判断。
不能说多了判断，程序就不好了，你这算是一点小强迫
没有说不好，而是说会增加很多时间去排错。
我打个比方，我读a表的b字段，如果他等于某值我就去执行某个过程。
但在这之前你得判断他是不是空，如果有空，你就不能拿他去运算，不然就出错。
如果你的程序涉及到100个表，这些表相互关联，
这个null的判断就要命了，而且我个人的软件中，大部分的null判断没有意义。
我更倾向于在数据库中设置默认值或者sql语句中设置，基本上就不用再用其他时间排错了。
当然，我希望能找到更好的办法。

Answer 15

同意，代码中加入判断，显得可读性差了，但是稳定性回复了，至于数据库中是否要设置默认值，看你的业务需求了，有些情况下，在程序中可能就是要读取到null值呢，甚至要根据null值进行判断。
不能说多了判断，程序就不好了，你这算是一点小强迫
没有说不好，而是说会增加很多时间去排错。
我打个比方，我读a表的b字段，如果他等于某值我就去执行某个过程。
但在这之前你得判断他是不是空，如果有空，你就不能拿他去运算，不然就出错。
如果你的程序涉及到100个表，这些表相互关联，
这个null的判断就要命了，而且我个人的软件中，大部分的null判断没有意义。
我更倾向于在数据库中设置默认值或者sql语句中设置，基本上就不用再用其他时间排错了。
当然，我希望能找到更好的办法。
可以设置默认的就设置默认，但是并不是所有的字段都是有默认值的，而且即使有默认值，该判断还是要判断的，这是代码的逻辑问题，你总不能说：我的程序一定要按照这个流程走，按照其他流程走，就不行，你这是在将业务定死了，你总不能说，代码出bug了，是因为测试不按照你设定的流程走吧，所以这个判断是个基础，不过你可以将数据中操作封装起来，是底层交给上层使用前，已经判断好。

Answer 16

在代码中判断吧。在dbhelp判断处理。我觉得并不会导致代码的可读性变差呀

Answer 17

同意，代码中加入判断，显得可读性差了，但是稳定性回复了，至于数据库中是否要设置默认值，看你的业务需求了，有些情况下，在程序中可能就是要读取到null值呢，甚至要根据null值进行判断。
不能说多了判断，程序就不好了，你这算是一点小强迫
没有说不好，而是说会增加很多时间去排错。
我打个比方，我读a表的b字段，如果他等于某值我就去执行某个过程。
但在这之前你得判断他是不是空，如果有空，你就不能拿他去运算，不然就出错。
如果你的程序涉及到100个表，这些表相互关联，
这个null的判断就要命了，而且我个人的软件中，大部分的null判断没有意义。
我更倾向于在数据库中设置默认值或者sql语句中设置，基本上就不用再用其他时间排错了。
当然，我希望能找到更好的办法。
你有认真的看我的回复吗？我之前给你说了，如果你使用inner join，那么不会出现任何一个null，但是数据会不完整，只要你不是inner join，关联主子表，只要不是一对一的关系，或多或少都会出现null，这个根本是无法避免的，对不对？所以该判断的时候还是需要在C#中判断，你单独看每一张表，有可能一个null也没有

Answer 18

你的问题仅出现在int,float,double,date,uint,ushort,long等类型所出现的问题。有一种数据库中和你mode中都用字符串来解决，每次使用进行转换，或者在类型前加一个“?”来解决，就可以接收数据库中的null值

Answer 19

我一般都是在SQL查询过程中过滤掉的，性能肯定有点影响，但是是能接受范围内我觉得就可以了。

Answer 20

isnull(字段,默认值)     就用这个把，别多想。效率不低

Answer 21

简单，你把所有的字段设置为非空的，并且设置一个默认值就不用验证从数据库里取的数据是不是null了
不一定的。如果有a表和b表，你关联a表和b表的时候，b表没有相应的记录，它就null。而且和上面问的一样，会不会增加存储空间，如果你全部设置了默认值。

你写sql语句的时候不会加个ifnull isnull？

Answer 22

其实就是找一个性价比合适的方法。
比如我查找一个员工的权限，他的权限有几十项，我一个一个去判断null么？
这不科学对不对。