事实上，我在处理Oracle时遇到了困难，包括无效的datetime值(不能打印，转换或任何东西，只是用DUMP()函数查看)，允许将其插入到数据库中，显然是通过一些有bug的客户端版本作为二进制列!保护数据库完整性就说这么多!

Oracle对null链接的处理:

http://digitalbush.com/2007/10/27/oracle-9i-null-behavior/

http://jeffkemponoracle.com/2006/02/empty-string-andor-null.html

我相信答案是甲骨文非常非常古老。

早在SQL标准出现之前，Oracle的设计决定是VARCHAR/VARCHAR2列中的空字符串为NULL，并且只有一种意义上的NULL(有关系理论家会区分从未提示的数据、存在答案但用户不知道的数据、没有答案的数据等等，所有这些都构成了某种意义上的NULL)。

By the time that the SQL standard came around and agreed that NULL and the empty string were distinct entities, there were already Oracle users that had code that assumed the two were equivalent. So Oracle was basically left with the options of breaking existing code, violating the SQL standard, or introducing some sort of initialization parameter that would change the functionality of potentially large number of queries. Violating the SQL standard (IMHO) was the least disruptive of these three options.

Oracle保留了在未来的版本中更改VARCHAR数据类型以遵循SQL标准的可能性(这就是为什么每个人都在Oracle中使用VARCHAR2，因为数据类型的行为保证在未来保持不变)。

甲骨文公司副总裁汤姆·凯特:

长度为0的varchar被视为 NULL。 不被视为NULL。 当赋值给char(1)时变成 ' '(字符类型是空白填充的 字符串)。 当分配给varchar2(1)时 变成"，长度为零 字符串和零长度的字符串是 Oracle中的NULL(它不是长”)

Oracle文档提醒开发人员注意这个问题，至少可以追溯到版本7。

Oracle选择用“不可能值”技术来表示null。例如，数值位置中的NULL将被存储为“负零”，这是一个不可能的值。任何由计算产生的负0将在存储之前转换为正0。

Oracle还错误地认为长度为0的VARCHAR字符串(空字符串)是一个不可能的值，并且是表示NULL的合适选择。事实证明，空字符串远非一个不可能的值。它甚至是字符串连接操作下的恒等式!

Oracle文档警告数据库设计人员和开发人员，Oracle的某些未来版本可能会出现这种情况 打破空字符串和NULL之间的这种关联，并打破依赖于这种关联的任何代码。

除了不可能的值之外，还有一些技术可以标记null，但Oracle没有使用它们。

(我上面用的“位置”这个词是指行和列的交点。)

I suspect this makes a lot more sense if you think of Oracle the way earlier developers probably did -- as a glorified backend for a data entry system. Every field in the database corresponded to a field in a form that a data entry operator saw on his screen. If the operator didn't type anything into a field, whether that's "birthdate" or "address" then the data for that field is "unknown". There's no way for an operator to indicate that someone's address is really an empty string, and that doesn't really make much sense anyways.

因为不将其处理为NULL也不是特别有用。

如果你在Oracle上在这方面犯了错误，你通常会马上注意到。然而，在SQL server中，它似乎是可以工作的，并且只有当有人输入空字符串而不是NULL时才会出现问题(可能来自。net客户端库，其中NULL与“”不同，但您通常将它们视为相同的)。

我并不是说甲骨文是对的，但在我看来，这两种方法都差不多一样糟糕。

首先，null和空字符串在Oracle中并不总是被视为相同的。根据定义，空字符串是不包含字符的字符串。这和null完全不一样。根据定义，NULL表示没有数据。

大约在五六年以前，Oracle对空字符串的处理与null是不同的。然而，像null一样，null字符串等于所有东西，不同于所有东西(我认为这对null来说很好，但对null字符串来说完全错误)，至少长度(null字符串)会返回0，因为它应该因为null字符串是一个零长度的字符串。

目前在Oracle中，长度(null)返回null，我猜是可以的，但长度(空字符串)也返回null，这是完全错误的。

我不明白为什么他们决定把这两种不同的“价值观”一视同仁。它们意味着不同的东西，程序员应该有能力以不同的方式处理它们。他们改变了他们的方法，这一事实告诉我，他们真的不知道应该如何对待这些价值。

空字符串与NULL相同，因为与两者(空字符串和NULL)不相同的情况相比，它是“较轻的邪恶”。

在NULL和空字符串不相同的语言中，必须始终检查这两个条件。

根据官方的11g文件

Oracle数据库当前将长度为0的字符值视为null。然而，在未来的版本中可能不会继续如此，Oracle建议您不要将空字符串视为null。

可能的原因

val IS NOT NULL比val更可读!= " 不需要检查val != "和val IS NOT NULL这两个条件

书中的例子

   set serveroutput on;   
    DECLARE
    empty_varchar2 VARCHAR2(10) := '';
    empty_char CHAR(10) := '';
    BEGIN
    IF empty_varchar2 IS NULL THEN
    DBMS_OUTPUT.PUT_LINE('empty_varchar2 is NULL');
    END IF;


    IF '' IS NULL THEN
    DBMS_OUTPUT.PUT_LINE(''''' is NULL');
    END IF;

    IF empty_char IS NULL THEN
    DBMS_OUTPUT.PUT_LINE('empty_char is NULL');
    ELSIF empty_char IS NOT NULL THEN
    DBMS_OUTPUT.PUT_LINE('empty_char is NOT NULL');
    END IF;

    END;