标签: rdbms

我想知道是否有人可以验证我对这 3 个与 Oracle 数据库相关的术语之间差异的理解。

许多来源混淆了这些术语并且没有详细解释它们，因此查找信息有点困难。

从我收集到的：

1. 提交和快速提交是一回事，所有提交都是快速提交。
2. 快速提交本质上仅更新撤消/回滚段标头的事务表中的标志以指示事务已提交。然而，实际块没有被重新访问，这意味着位于数据块头部的感兴趣事务列表（ITL）中的撤消字节地址（UBA）仍然指向相应撤消段的事务表。此外，相应行的锁字节不会被释放，并且 ITL 中的锁计数不变（行仍然被锁定）。
3. 在一个提交清除，块被重新与ITL与提交SCN更新。然而，ITL 中的锁计数和每行存储的锁字节仍然没有更新（行仍然被锁定，就像在快速提交中一样），即使块被更改，这也不会生成重做。
4. 正常提交的块（== 快速提交）将在下次触摸时进行延迟块清除（并生成重做）。
5. 进行了提交清除的块将在下次触摸时进行延迟日志记录块清除（并生成重做）。

希望有人可以验证这些要点！谢谢！

背景：
我创建了一个 Web 应用程序，我希望它能够合理地扩展。我知道我不是 Google 或 Twitter，但我的应用程序为每个用户使用了相当大量的数据，因此对数据的要求相当高。我想准备好进行合理的扩展，而不必在以后重新构建所有内容。

我认为自己是一名软件开发人员，而不是数据库专家。这就是我在这里发帖的原因。希望有更多数据库专业知识的人可以给我建议。

拥有相对大量的用户，但与 Facebook 的数字完全不同，我希望有一个如下所示的数据库：

一张“大桌子”：

• 2.5 亿条记录
• 20列
• 大约 100 GB 的数据
• 有一个索引 bigint(20) 外键
• 有一个索引 varchar(500) string_id 列
• 有一个 int(11)“值”列

其他 4 个表：

• 每个 1000 万条记录
• 每个大约 2 - 4 GB 的数据
• 这些表中的每一个都有 4 - 8 列
• 一列是日期时间 date_created
• 一列是 varchar(500) string_id 列
• 将在连接中选择这些表中的每一个中的一或两列

这些表之一用于存储平均值——它的架构是 bigint(20) id、varchar(20) string_id、datetime date_created、float average_value

我想要做什么——两个相对昂贵的查询：

1. 计算新的平均值：

   • 使用外键，从大表中选择多达几百万条单独的记录。
   • 计算一个新的平均值，按 string_id 分组。
   • 将结果插入到平均值表中。
   • 按照目前的构造，此查询使用两个连接。

2. 为服务用户创建非规范化的只读记录：

   • 使用外键从大表中选择 1,000-40,000 条记录。
   • 使用字符串 id 列与最新记录上的其他四个表中的每一个连接。
   • 将结果插入到非规范化表中。
   • 这些记录供前端用来向用户展示信息。
   • 按照目前的构造，此查询使用四个连接。

我计划在批处理后端数据库上运行这些昂贵的查询中的每一个，该数据库将其结果推送到处理用户请求的实时前端数据库服务器。这些查询将定期运行。我还没有决定多久。平均查询可能每天进行一次。非规范化查询需要更频繁——也许每隔几分钟。

这些查询中的每一个当前在 …

我的要求是在触发器执行时执行像 (ls) 或 C 程序这样的系统命令。有没有办法创建一个触发函数来解决这个问题。

如果记录当前正被另一个进程使用，两种形式的锁定都会导致进程等待记录的正确副本。对于悲观锁定，锁定机制来自数据库本身（本地锁定对象），而对于乐观锁定，锁定机制是某种形式的行版本控制，例如时间戳，用于检查记录是否“过时”。

但两者都会导致第二个进程挂起。所以我问：为什么乐观锁定通常被认为比悲观锁定更快/更好？并且，是否存在悲观优于乐观的用例？提前致谢！

水平扩展/分布 RDBMS 困难的主要原因是因为遵守 ACID 事务吗？是多个表如此相互关联的事实，还是其他原因？

我的印象是，它\xe2\x80\x99主要是ACID要求，因为集群中的不同节点在任何给定时间可能有不同的值。但哎呀，我\xe2\x80\x99m 模糊了 ACID 的工作原理。

相反，为什么某些 NoSQL 数据库更容易分发？我对分布式数据库了解不够，无法理解为什么一个数据库可以轻松分布式，而另一个数据库则不能。

任何人都可以透露一些信息吗？

Astor Data、Greenplum 和 GridSQL 都允许对 SQL 查询进行大规模并行处理。它们也都是围绕 PostgreSQL 技术构建的。这仅仅是因为许可问题还是有其他原因？对我来说，它看起来像 MyISAM，不符合 ACID，因此不会遇到与 MVCC 相同的问题（如这里所见），因为 PostgreSQL 更适合构建高性能数据仓库。毕竟，就我所见，OLAP 负载不需要事务。

我在工作中被要求多次违反第一范式（跨列重复组，使用空/空值），“为了计算机处理能力”。简而言之，一个“学生”表应该至少有 8 个空字段（例如电话：telephone1、telephone2、telephone3...）而不是我的建议 - 一个包含电话号码（和可能的其他元数据）的“电话”表外键是学生证号。我的老板说最好以这种方式存储它们，因为“CPU 周期更少，这在 Web 平台中很重要”，而不是使用关系。我说，在最坏的情况下，它可以忽略不计。

在那个例子中，使用关系（假设在一个中等规模的 web 应用程序中用大量记录填充表）明显比使用那种表模式慢？

我目前正在制作一款 MMORPG 游戏，它可能有几千名玩家同时在线（可能不是；只是一厢情愿）。首先我们想使用 MySQL，但我听说它对于这种规模还不够快。

哪个 DBMS 足够快？它有多像 SQL Server（我在学校学过 SQL Server）？

我有这个查询：

UPDATE   (
    SELECT   h.valid_through_dt, h.LAST_UPDATE_TMSTMP
    FROM   ETL_FEE_SCH_TMP d, FEE_SCHEDULE_HISTORICAL h
    WHERE       h.FUND_ID = d.FUND_ID
    AND h.FEETYPE_NAME = d.FEETYPE_NAME
    AND h.BREAKPOINT_TYPE = d.BREAKPOINT_TYPE
    AND h.BREAKPOINT_QTY = d.BREAKPOINT_QTY
    AND h.LOW_BREAKPOINT_AMT = d.LOW_BREAKPOINT_AMT
    AND h.VALID_THROUGH = TO_DATE ('31-DEC-9999', 'dd-mon-yyyy')
    AND h.universe = 'DC'
    AND h.universe = d.universe
    AND EXISTS
    (
        SELECT 1
        FROM FEE_SCHEDULE s
        WHERE s.FUND_ID = h.FUND_ID
        AND s.FEETYPE_NAME = h.FEETYPE_NAME
        AND s.BREAKPOINT_TYPE = h.BREAKPOINT_TYPE
        AND s.BREAKPOINT_QTY = h.BREAKPOINT_QTY
        AND s.LOW_BREAKPOINT_AMT = h.LOW_BREAKPOINT_AMT
        AND s.universe = 'DC'
    )
) updateTable …

作为这个问题的后续行动，我有一个我自己的。

最初的问题涉及使用CASE超过 100 个选项的语句，并且该语句必须在 4 个地方使用 - 所以显然 SQL 非常多毛。OP 的问题与 SQL Server 2012 有关，但是我的问题是关于 PostgreSQL。

在我的回答中，我建议使用 aVIEW作为“一站式”解决方案 - 即声明VIEW一次，在任何地方使用它 - 这也适用于未来的任何查询及其任何变体。

另一位发帖人（@AndriyM）建议使用 aCROSS APPLY来解决该问题，这是另一种解决方案。PostgreSQL 语法是JOIN LATERAL

然后，我在原始答案中添加了 CTE（通用表表达式）作为另一种可能的解决方案。

因此，OP 现在有 5 个选项：

1. CASE
2. VIEW
3. JOIN LATERAL（CROSS APPLY对于 SQL Server）
4. CTE
5. Separate table

我排除了更改基础数据的选项，因为在本论坛中，顾问/DBA/程序员经常不允许更改基础数据 - 也使答案更有趣！

显然，CASE具有 > 100 个选项 (x4)的表达式非常麻烦和复杂 - 但什么时候使用是个好主意CASE，在什么时候它会变成减号而不是加号？

在我看来（不仅仅是因为这是我的答案！），aVIEW是最佳解决方案 …