标签: data-integrity

最近，我向同事解释了在数据库表中使用一列对数据进行排序的重要性，如果有必要这样做，例如按时间顺序排列的数据。这证明有点困难，因为他们可以简单地重新运行他们的查询，似乎无休止地，并且它总是会以相同的顺序返回相同的行集。

我之前已经注意到这一点，我真正能做的就是坚持他们信任我，而不是简单地假设数据库表的行为类似于传统的 CSV 或 Excel 文件。

例如，执行 (PostgreSQL) 查询

create table mytable (
    id INTEGER PRIMARY KEY,
    data TEXT
);
INSERT INTO mytable VALUES
    (0, 'a'),
    (1, 'b'),
    (2, 'c'),
    (3, 'd'),
    (4, 'e'),
    (5, 'f'),
    (6, 'g'),
    (7, 'h'),
    (8, 'i'),
    (9, 'j');

将创建一个具有清晰概念顺序的表格。以最简单的方式选择相同的数据是：

SELECT * FROM mytable;

总是给我以下结果：

 id | data 
----+------
  0 | a
  1 | b
  2 | c
  3 | d
  4 | e
  5 | f
  6 | g
  7 | h
  8 | …

有什么用log_bin_trust_function_creators？另外，参数的值是动态的吗？如果我重新启动 MySQL 服务，它会改变吗？

假设我想将电话号码存储在数据库中。我可以接受来自美国以外的电话号码。我将如何存储这些电话号码？

我正在使用 PostgreSQL，但我认为大多数高端数据库必须具有一些类似的功能，而且，它们的解决方案可能会启发我的解决方案，所以不要考虑这个特定于 PostgreSQL 的解决方案。

我知道我不是第一个尝试解决这个问题的人，所以我认为这里值得一问，但我正在尝试评估建模会计数据的成本，以便从根本上平衡每笔交易。会计数据是仅附加的。此处的总体约束（以伪代码编写）可能大致如下：

CREATE TABLE journal_entry (
    id bigserial not null unique, --artificial candidate key
    journal_type_id int references  journal_type(id),
    reference text, -- source document identifier, unique per journal
    date_posted date not null,
    PRIMARY KEY (journal_type_id, reference)
);

CREATE TABLE journal_line (
    entry_id bigint references journal_entry(id),
    account_id int not null references account(id),
    amount numeric not null,
    line_id bigserial not null unique,
    CHECK ((sum(amount) over (partition by entry_id) = 0) -- this won't work
);

显然，这样的检查约束永远不会起作用。它按行操作，可能会检查整个数据库。所以它总是会失败并且做起来很慢。

所以我的问题是对这种约束进行建模的最佳方法是什么？到目前为止，我基本上已经研究了两个想法。想知道这些是否是唯一的，或者是否有人有更好的方法（除了将其留给应用程序级别或存储过程）。

1. 我可以借用会计界关于原始分录和最终分录（普通日记帐与总分类帐）之间差异的概念的一页。在这方面，我可以将其建模为附加到日志条目的日志行数组，对数组强制执行约束（在 PostgreSQL 术语中，从 …

我正在设计我的第一个电子商务模式。我已经阅读了一段时间的主题，并且对 anorder_line_item和 a之间的关系感到有些困惑product

一个product可以被购买。它有各种细节，但最重要的是unit_price。

Anorder_line_item有一个外键，指向product_id购买的、quantity购买的和unit_price客户购买产品的时间点。

我读过的大部分内容都说应该明确添加unit_priceon order_line_item（即不通过 引用product_id）。有道理，因为商店将来可能会改变价格，这会弄乱订单报告、跟踪、完整性等。

我不明白的是，为什么直接将unit_price值保存到order_line_item?

创建一个记录unit_pricea 更改的审计/历史表不是更好product吗？

当order_line_item被创建，所述的外键product_audit表，并将该价格可以从那里检索（通过引用）。

在我看来，使用这种方法有很多好处（减少重复的数据、价格变化历史等），那么为什么不更频繁地使用它呢？我还没有遇到使用这种方法的电子商务模式的例子，我错过了什么吗？

UDPATE：我的问题似乎与Slowly Changed Dimension 相关。我仍然感到困惑，因为缓慢变化的维度与数据仓库和 OLAP 相关。那么，缓慢变化的维度类型可以应用于我的主要业务事务流程数据库 (OLTP) 吗？我想知道我是否混合了很多概念，非常感谢一些指导。

我想向一个非常大的表添加一个检查约束。就像是：

ALTER TABLE "accounts" ADD CONSTRAINT "positive_balance" CHECK ("balance" >= 0);

不幸的是 PostgreSQL 9.3 在约束检查完成之前阻止读取或写入。我通过启动一个事务，运行ALTER TABLE，然后打开第二个事务并检查在第一个事务完成之前我无法从表中读取或写入来验证这一点。

有什么办法可以在CHECK不锁定表的情况下添加此约束？

MSDN 说实数的范围是 - 3.40E + 38 到 -1.18E - 38, 0 和 1.18E - 38 到 3.40E + 38。显然真正的下限要低得多。以下脚本使用 1.401298E-45 填充 REAL 列：

CREATE TABLE a
  (
    r1 REAL NULL ,
    r2 REAL NULL ,
    r3 REAL NULL
  ) ;
GO
INSERT  INTO a
        ( r1, r2 )
VALUES  ( 1.18E-37, 10 ) ;
GO
DECLARE @i INT ;
SET @i = 1 ;

WHILE @i < 20 
  BEGIN ;

    UPDATE  a
    SET     r1 = r1 / r2 ; …

MySQL InnoDB 允许我们通过设置innodb_doublewrite = 0. 其他数据库似乎不允许调整此设置。

如果我们禁用双写缓冲，InnoDB 如何仍然能够保持数据完整性和ACID？

在什么情况下关闭 InnoDB 双写缓冲区是安全的？

无论我读过 CAP 还是 ACID，我都看到一致性被用来确保 DB 完整性约束。所以，我不明白，为什么用两个术语来指代同一件事，或者完整性和一致性之间存在差异？

我读到了

总之，原子性、一致性、隔离性、持久性是事务的属性。确实，原子性+隔离性足以让您滚动自己的一致性。但是我们也可以滚动我们自己的原子性，滚动我们自己的隔离，滚动我们自己的持久性（durability）。当我们推出自己的产品时，我们必须用自己的血汗和括号为功能买单。我们并没有说这些属性是由交易系统提供给我们的。

这表明一致性是用户应用程序可以在数据库完整性约束之上提供的东西。这不是由数据库提供的属性，因为 AID 属性是。为什么要像对系统提供的其他 AID 属性一样给 C 标题？

MySQL 允许创建跨数据库外键 - 但这是确保数据完整性的好方法吗？是否可以给出一般性答案，还是取决于项目？它有哪些优势和威胁？

假设有两个数据库，A 和 B，它们通常存储不同的信息用于不同的目的和不同的数据上传方式，但是数据的某些部分可能出现在两个数据库中。现在让我们假设一个人想要确保这个小交叉点的所有东西都已经在 B 中结束了。在这种情况下，外键是个好主意吗？