2

多年来我一直在做关系数据库的事情,但最近已经进入 Cassandra/Redis 领域。NoSQL 对于我们正在做的事情是有意义的,所以这很好。

今天在定义 Cassandra 列族时,我想到了一个问题:在关系数据库中,为什么 DDL 不让我们以数据库引擎本身可以本地管理由此产生的一致性问题的方式定义非规范化规则。换句话说,当关系数据库程序员通过非规范化来实现性能目标时……为什么他/她要通过专门编写的 SQL 来保持一致性?

也许我缺少一些明显的东西?这样的建议是否有一些愚蠢的原因,因为在我看来,拥有这种能力可能非常有用。

编辑:

感谢到目前为止的反馈。我仍然觉得我手上有一个悬而未决的问题(也许是因为它表达得不好)。我了解物化视图试图为非规范化数据提供引擎管理的一致性。但是,我的理解是它们不会随着基础表的更改而立即更新。如果这是真的,这意味着引擎真的不是管理由非规范化引起的一致性问题......至少不是在写入时。我的意思是,当需要针对复杂的关系模型扩展具有繁重读取负载的系统时,没有真正的、功能丰富的、引擎管理的非规范化的规范化数据结构会阻碍关系数据库引擎。我认为调整物化视图刷新率确实等同于 Cassandra 等 NoSQL 引擎提供的可调“最终一致性”。我需要了解引擎如何有效地同步其物化视图。为了相对于 NoSQL 选项被认为是可行的,同步视图所需的时间需要随着添加/更新的行数线性增加。

无论如何,我会再考虑一下并重新编辑。希望有一些想象中的 DDL 的代表性例子。

4

2 回答 2

2

一些关系数据库系统能够在一定程度上保持非规范化数据的一致性(如果我理解正确的话)。

Oracle, 这称为materialized views, 在SQL Serverindexed views

基本上,这意味着您可以创建一个自维护的非规范化表作为SQL查询的结果并对其进行索引:

CREATE VIEW a_b
WITH SCHEMABINDING
AS
SELECT  b.id AS id, b.value, b.a_id, a.property
FROM    dbo.b b
JOIN    dbo.a a
ON      a.id = b.a_id

结果视图 ,a_b如果它是一个真实的表,将会违反,2NF因为property它在功能上取决于a_id哪个不是候选键。但是,数据库系统维护这种功能依赖关系,您可以创建一个复合索引,例如(value, property).

甚至本身不支持物化视图的也能够维护某种非规范化表MySQLPostgreSQL

例如,当您FULLTEXT在 中的一列或一组列上创建索引时MySQL,您会同时获得两个索引:第一个索引包含每个记录中每个不同单词的一个条目(参考原始记录id),第二个索引包含整个表中每个单词的一条记录,以及总字数。这允许快速搜索单词并按相关性排序。

总字数表当然取决于单个字表,因此违反5NF了 ,但是,系统再次保持这种依赖性。

GIN对和中的GIST索引进行了类似的操作PostgreSQL

当然,并非所有可能的非规范化都可以维护,这意味着您不能实时物化和索引任何查询:有些维护成本太高,有些理论上可行但在实际系统中未实现,等等。

但是,您可以在触发器、存储过程或其他任何东西中使用自己的逻辑来维护它们,这正是它们的用途。

于 2011-05-04T21:21:18.920 回答
1

RDBMS 中的非规范化是一种特殊情况:不是标准。只有当你有一个经过验证的案例时才会这样做。如果您预先设计非规范化数据,那么您已经迷路了。

鉴于每种情况在定义上都是“特殊的”,那么如何有标准的 SQL 构造来维护非规范化的数据。

RDBMS 与 NoSQL 的不同之处在于它旨在与规范化设计一起使用。恕我直言,你不能像这样比较 RDBMS 和 NoSQL

于 2011-05-09T16:37:26.057 回答