4

我正在做一个项目，需要为业务逻辑存储 30 个不同的字段，稍后将用于为每个字段生成报告

30 个不同的字段不是一次写的，业务逻辑有这么多事务，它会是这样的：

Transaction 1, update field 1-4
Transaction 2, update field 3,5,9
Transaction 3, update field 8,12, 20-30
...
...

注意每笔交易（都属于一个业务逻辑）将更新任意数量的字段而不是按任何特定顺序。

我想知道我的数据库设计是最好的：

  1. 在 postgres 数据库中有 30 列代表这 30 个不同的字段。

  2. 以 xml 或 json 的形式存储 30 个文件，并将其存储在 postgres 的一列中。

1或2哪个更好？

如果我选择 1>：

我知道从编程角度来看更容易因为这样我不需要读取整个 xml/json 并且只更新几个字段然后写回数据库，我只能更新每个事务所需的几列。

如果我选择 2>：

我可能会将该表通用地重用于其他东西，因为 blob 列中的内容只是 xml。但是，仅仅因为它有一个存储 xml 的 blob 列就使用泛型表来存储与业务逻辑完全无关的东西是错误的吗？这确实有可能节省创建几个新表的工作量。但是这种重用表的通用想法在 RDBMS 中是错误的吗？

另外，通过选择 2>，我似乎能够处理潜在的变化，比如更改某些字段/添加更多字段？至少看起来我不需要更改数据库表。但我仍然需要更改 c++ 和 c# 代码以在内部处理更改，不确定这是否有任何优势。

我在数据库设计方面没有足够的经验，所以我无法决定选择哪一个。任何输入表示赞赏。

注意，我很有可能暂时不需要对这 30 个列进行索引或搜索，如果我选择 2>，则会在额外的列上创建主键。但我不确定以后是否需要我根据这些列/字段中的任何一个进行搜索。

基本上我的所有字段都是从需求文档中预定义的，它们通常喜欢简单的字段：

field1: value(max len 10)
field2: value(max len 20)
...
field20: value((max len 2)

没有嵌套字段。是否值得为每个字段创建 20 列（有些是字符串，如日期/时间，有些是字符串，有些是整数等）。

2> 将不同的业务逻辑放在共享表中是一个糟糕的设计理念吗？如果因为它们共享相同的结构而仅将其放入共享表中？例如，它们都有日期时间列、主键和内部具有不同业务逻辑的 xml 列？这样我们就可以安全地创建新表……这种节省的努力值得吗？

4

3 回答 3

4

始终将您的 XML/JSON 字段作为单独的字段存储在关系数据库中。这样做您将保持您的数据库规范化，允许数据库使用查询/索引等来完成它的工作。您将让其他开发人员免于解读您的 XML/JSON 字段的麻烦。

从 XML/JSON 中提取字段并在需要添加字段时进行维护可能需要更多的工作，但是一旦您创建了一个或多个类来这样做，就会消除障碍，而且不仅仅是为神秘的 blob 字段做准备。

于 2012-11-08T17:28:01.177 回答
3

通常，明智的做法是将 JSON 或 XML 文档拆分出来并将其存储为单独的列。这使您能够在列上设置约束以进行验证和检查、索引列、为每个字段使用适当的数据类型，并且通常使用数据库的功能。

将其映射到对象/从对象映射通常不太难，因为有很多工具可以做到这一点。例如，Java 提供 JAXB 和 JPA。

当您事先不知道 JSON 或 XML 文档的字段将是什么或将有多少字段时，将其拆分不是一个好主意的主要时间。在这种情况下，您实际上只有两个选择 - 使用类似 EAV 的数据模型，或者将文档直接存储为数据库字段。

在这种情况下（仅在这种情况下），我会考虑将文档直接存储在数据库中。PostgreSQL 的 SQL/XML 支持意味着您仍然可以在表达式上创建表达式索引xpath，并且可以使用触发器进行某些验证。

这不是一个好的选择，只是 EAV 通常是一个更糟糕的选择。

如果文档是“扁平的”——即没有嵌套的单级键和值——考虑将其存储为hstore相反，因为hstore数据类型更强大。

于 2012-11-09T01:27:21.717 回答
2

(1) 更标准，有充分的理由。使数据库能够对一件事的搜索和索引等事情进行繁重的工作。

于 2012-11-08T17:19:24.107 回答