相关疑难解决方法(0)

存储可能是多种不同类型的值的正确方法

我有一个Answers表和一个Questions表。

答案表中有值,但根据问题,这个值可以是一个bitnvarcharnumber(到目前为止)。该问题有其意的答案值类型应该是什么概念。

在某一点或另一点解析这些Answer值非常重要,因为至少需要比较这些数字。

对于更多的上下文,问题和潜在答案(通常是允许文本框类型输入的数据类型)由某些用户在各种调查中提供。然后由其他指定用户提供答案。

我考虑过的几个选项是:

A. 根据预期类型(在问题中记录)不同解析的 XML 或字符串

B. 三个单独的表,它们引用(或被引用)Answer 表并根据预期类型连接到其中。在这种情况下,我不确定设置约束以确保每个问题只有一个答案的最佳方法,或者是否应该将答案留给应用程序。

C. Answer 表上的三个单独的列,可以根据预期的类型进行检索。

我很乐意就这些方法的优缺点或我没有考虑过的替代方法获得一些意见。

database-design sql-server eav

13
推荐指数
1
解决办法
9116
查看次数

在 PostgreSQL 中不为不能为空的字段指定 NOT NULL 的后果是什么?

我有一个应用程序(数据存储在 PostgreSQL 中),其中表中的大多数字段始终不为空,但这些表的架构并未强制执行此操作。例如看看这个假表:

CREATE TABLE "tbl" (
    "id" serial,
    "name" varchar(40),
    "num" int,
    "time" timestamp
    PRIMARY KEY ("id"),
    UNIQUE ("id")
);
Run Code Online (Sandbox Code Playgroud)

此外namenum,time没有明确声明为NOT NULL,实际上它们是,因为强制执行发生在应用程序端。


我的感觉是应该改变它,但相反的是应用程序级别确保这里不能出现空值并且没有其他人手动修改表。

我的问题是:通过设置一个显式NOT NULL约束?

我们有一个很好的代码审查流程和一个相当好的文档,所以一些新人会提交打破这个限制的东西的可能性并不足以证明改变是合理的。

这不是我的决定,所以这正是我寻找其他理由的原因。在我看来,如果某些内容不能为空并且数据库允许您指定某些内容不为空 - 那就去做吧。特别是如果更改非常简单。

schema postgresql null

10
推荐指数
2
解决办法
2438
查看次数

标签 统计

database-design ×1

eav ×1

null ×1

postgresql ×1

schema ×1

sql-server ×1