【问题标题】:Dealing with null values versus empty strings in a database when only empty strings are coming from the client via HTTP POST当只有空字符串通过 HTTP POST 来自客户端时,处理数据库中的空值与空字符串
【发布时间】:2010-10-09 02:45:38
【问题描述】:

我的 MySQL 数据库有仔细定义的字段。某些字段,如果有可能是未知的,则允许 NULL 值。

我正在编写一个基于 Web 的 CMS 来处理所述数据库中的数据。显然,HTML 表单中的 post 数组从不包含空值,只包含空字符串。

我不想通过添加“NULL 复选框”或类似的东西来混淆我的 CMS 用户,但我无法从帖子数组中判断一个字段应该为空还是空。

我是否应该在保存允许空值的字段时将所有空字符串转换为 NULL 值?

对于这类难题有哪些好的做法?

【问题讨论】:

    标签: mysql database content-management-system null


    【解决方案1】:

    这是一个棘手的问题。当然,用户无法知道他们是要插入空字符串还是根本不插入。所以答案真的取决于你。是否允许用户输入空字符串?它这样做有什么意义吗?如果空字符串意味着 NULL 字符串不具有的含义并且定义明确,请继续并允许两者。

    如果它们之间没有区别,请选择一个并坚持下去。我个人不明白为什么你需要保留这样的空字符串,它只会让事情变得更加混乱。只需坚持使用 NULL 来表示没有数据。

    现在就做出决定,记录下来并坚持下去。

    【讨论】:

      【解决方案2】:

      你真的想处理实际正确的NULL,以及它棘手的three-value logic吗?

      根据我的经验,您实际上很少需要 NULL 带来的明确不确定性。为用户不想填写的值存储一个空字符串通常更实用。然后,您可以继续进行搜索,例如 WHERE t.field<>'x'WHERE t0.field=t1.field,而不必担心当其中一个或两个都为空时这会对您的布尔逻辑产生什么影响。

      如果您已经有了一个依赖于 null 不确定性的工作数据库,并且这是您要求的内在部分,那么很好,坚持使用 null(在这种情况下,您可能必须转换空用户在可空字段中输入 null 只是因为没有最终用户永远能够理解 nothing 和 null 之间的概念区别)。

      但我个人仍然只对可选的外键引用使用空值(当不使用单独的连接表时)。

      【讨论】:

        猜你喜欢
        • 2013-09-07
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2017-09-21
        • 2022-06-30
        • 2017-12-03
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多