Merge branch 'master' into master

fuxuemingzhu · Sep 27, 2021 · cc49c41 · cc49c41
2 parents b4b3d1b + e98e415
commit cc49c41
Show file tree

Hide file tree

Showing 6 changed files with 11 additions and 5 deletions.
diff --git a/README.md b/README.md
@@ -152,6 +152,8 @@
 
 | ISSUE & Pull Requests                          | USER                                                         | Title                                                        |
 | ----------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+|  [132](https://github.com/Vonng/ddia/pull/132)  |  [@fuxuemingzhu](https://github.com/fuxuemingzhu)  |   ch3: 优化一处容易产生歧义的翻译  |
+|  [131](https://github.com/Vonng/ddia/pull/131)  |  [@rwwg4](https://github.com/rwwg4)  |   ch6: 修正两处错误的翻译  |
 |  [129](https://github.com/Vonng/ddia/pull/129)  |  [@anaer](https://github.com/anaer)  |   ch4: 修正两处强调文本和四处代码变量名称  |
 |  [128](https://github.com/Vonng/ddia/pull/128)  |  [@meilin96](https://github.com/meilin96)  |   ch5: 修正一处错误的引用  |
 |  [126](https://github.com/Vonng/ddia/pull/126)  |  [@cwr31](https://github.com/cwr31)  |   ch10: 修正一处错误的翻译（功能 -> 函数）  |

diff --git a/ch3.md b/ch3.md
@@ -297,7 +297,7 @@ B树在数据库体系结构中是非常根深蒂固的，为许多工作负载
 
 ### 其他索引结构
 
-到目前为止，我们只讨论了关键值索引，它们就像关系模型中的**主键（primary key）** 索引。主键唯一标识关系表中的一行，或文档数据库中的一个文档或图形数据库中的一个顶点。数据库中的其他记录可以通过其主键（或ID）引用该行/文档/顶点，并且索引用于解析这样的引用。
+到目前为止，我们只讨论了键值索引，它们就像关系模型中的**主键（primary key）** 索引。主键唯一标识关系表中的一行，或文档数据库中的一个文档或图形数据库中的一个顶点。数据库中的其他记录可以通过其主键（或ID）引用该行/文档/顶点，并且索引用于解析这样的引用。
 
 有二级索引也很常见。在关系数据库中，您可以使用 `CREATE INDEX` 命令在同一个表上创建多个二级索引，而且这些索引通常对于有效地执行联接而言至关重要。例如，在[第二章](ch2.md)中的[图2-1](img/fig2-1.png)中，很可能在 `user_id` 列上有一个二级索引，以便您可以在每个表中找到属于同一用户的所有行。
 
@@ -306,6 +306,7 @@ B树在数据库体系结构中是非常根深蒂固的，为许多工作负载
 #### 将值存储在索引中
 
 索引中的键是查询搜索的内容，而其值可以是以下两种情况之一：它可以是所讨论的实际行（文档，顶点），也可以是对存储在别处的行的引用。在后一种情况下，行被存储的地方被称为**堆文件（heap file）**，并且存储的数据没有特定的顺序（它可以是仅追加的，或者可以跟踪被删除的行以便用新数据覆盖它们后来）。堆文件方法很常见，因为它避免了在存在多个二级索引时复制数据：每个索引只引用堆文件中的一个位置，实际的数据保存在一个地方。
+
 在不更改键的情况下更新值时，堆文件方法可以非常高效：只要新值的字节数不大于旧值，就可以覆盖该记录。如果新值更大，情况会更复杂，因为它可能需要移到堆中有足够空间的新位置。在这种情况下，要么所有的索引都需要更新，以指向记录的新堆位置，或者在旧堆位置留下一个转发指针【5】。
 
 在某些情况下，从索引到堆文件的额外跳跃对读取来说性能损失太大，因此可能希望将索引行直接存储在索引中。这被称为聚集索引。例如，在MySQL的InnoDB存储引擎中，表的主键总是一个聚集索引，二级索引则引用主键（而不是堆文件中的位置）【31】。在SQL Server中，可以为每个表指定一个聚集索引【32】。

diff --git a/ch6.md b/ch6.md
@@ -192,7 +192,7 @@
 
 	也许你想知道为什么我们不使用 ***取模（mod）***（许多编程语言中的％运算符）。例如，`hash(key) mod 10`会返回一个介于0和9之间的数字（如果我们将散列写为十进制数，散列模10将是最后一个数字）。如果我们有10个节点，编号为0到9，这似乎是将每个键分配给一个节点的简单方法。
 
-	模N（$mod N$）方法的问题是，如果节点数量N发生变化，大多数密钥将需要从一个节点移动到另一个节点。例如，假设$hash(key)=123456$。如果最初有10个节点，那么这个键一开始放在节点6上（因为$123456\ mod\  10 = 6$）。当您增长到11个节点时，密钥需要移动到节点3（$123456\ mod\ 11 = 3$），当您增长到12个节点时，需要移动到节点0（$123456\ mod\ 12 = 0$）。这种频繁的举动使得重新平衡过于昂贵。
+	模N（$mod N$）方法的问题是，如果节点数量N发生变化，大多数键将需要从一个节点移动到另一个节点。例如，假设$hash(key)=123456$。如果最初有10个节点，那么这个键一开始放在节点6上（因为$123456\ mod\  10 = 6$）。当您增长到11个节点时，键需要移动到节点3（$123456\ mod\ 11 = 3$），当您增长到12个节点时，需要移动到节点0（$123456\ mod\ 12 = 0$）。这种频繁的举动使得重新平衡过于昂贵。
 
 	我们需要一种只移动必需数据的方法。
 

diff --git a/zh-tw/README.md b/zh-tw/README.md
@@ -152,6 +152,8 @@
 
 | ISSUE & Pull Requests                          | USER                                                         | Title                                                        |
 | ----------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+|  [132](https://github.com/Vonng/ddia/pull/132)  |  [@fuxuemingzhu](https://github.com/fuxuemingzhu)  |   ch3: 最佳化一處容易產生歧義的翻譯  |
+|  [131](https://github.com/Vonng/ddia/pull/131)  |  [@rwwg4](https://github.com/rwwg4)  |   ch6: 修正兩處錯誤的翻譯  |
 |  [129](https://github.com/Vonng/ddia/pull/129)  |  [@anaer](https://github.com/anaer)  |   ch4: 修正兩處強調文字和四處程式碼變數名稱  |
 |  [128](https://github.com/Vonng/ddia/pull/128)  |  [@meilin96](https://github.com/meilin96)  |   ch5: 修正一處錯誤的引用  |
 |  [126](https://github.com/Vonng/ddia/pull/126)  |  [@cwr31](https://github.com/cwr31)  |   ch10: 修正一處錯誤的翻譯（功能 -> 函式）  |

diff --git a/zh-tw/ch3.md b/zh-tw/ch3.md
@@ -297,7 +297,7 @@ B樹在資料庫體系結構中是非常根深蒂固的，為許多工作負載
 
 ### 其他索引結構
 
-到目前為止，我們只討論了關鍵值索引，它們就像關係模型中的**主鍵（primary key）** 索引。主鍵唯一標識關係表中的一行，或文件資料庫中的一個文件或圖形資料庫中的一個頂點。資料庫中的其他記錄可以透過其主鍵（或ID）引用該行/文件/頂點，並且索引用於解析這樣的引用。
+到目前為止，我們只討論了鍵值索引，它們就像關係模型中的**主鍵（primary key）** 索引。主鍵唯一標識關係表中的一行，或文件資料庫中的一個文件或圖形資料庫中的一個頂點。資料庫中的其他記錄可以透過其主鍵（或ID）引用該行/文件/頂點，並且索引用於解析這樣的引用。
 
 有二級索引也很常見。在關係資料庫中，您可以使用 `CREATE INDEX` 命令在同一個表上建立多個二級索引，而且這些索引通常對於有效地執行聯接而言至關重要。例如，在[第二章](ch2.md)中的[圖2-1](../img/fig2-1.png)中，很可能在 `user_id` 列上有一個二級索引，以便您可以在每個表中找到屬於同一使用者的所有行。
 
@@ -306,7 +306,8 @@ B樹在資料庫體系結構中是非常根深蒂固的，為許多工作負載
 #### 將值儲存在索引中
 
 索引中的鍵是查詢搜尋的內容，而其值可以是以下兩種情況之一：它可以是所討論的實際行（文件，頂點），也可以是對儲存在別處的行的引用。在後一種情況下，行被儲存的地方被稱為**堆檔案（heap file）**，並且儲存的資料沒有特定的順序（它可以是僅追加的，或者可以跟蹤被刪除的行以便用新資料覆蓋它們後來）。堆檔案方法很常見，因為它避免了在存在多個二級索引時複製資料：每個索引只引用堆檔案中的一個位置，實際的資料儲存在一個地方。
-在不更改鍵的情況下更新值時，堆檔案方法可以非常高效：只要新值不大於舊值，就可以覆蓋該記錄。如果新值更大，情況會更復雜，因為它可能需要移到堆中有足夠空間的新位置。在這種情況下，要麼所有的索引都需要更新，以指向記錄的新堆位置，或者在舊堆位置留下一個轉發指標【5】。
+
+在不更改鍵的情況下更新值時，堆檔案方法可以非常高效：只要新值的位元組數不大於舊值，就可以覆蓋該記錄。如果新值更大，情況會更復雜，因為它可能需要移到堆中有足夠空間的新位置。在這種情況下，要麼所有的索引都需要更新，以指向記錄的新堆位置，或者在舊堆位置留下一個轉發指標【5】。
 
 在某些情況下，從索引到堆檔案的額外跳躍對讀取來說效能損失太大，因此可能希望將索引行直接儲存在索引中。這被稱為聚集索引。例如，在MySQL的InnoDB儲存引擎中，表的主鍵總是一個聚集索引，二級索引則引用主鍵（而不是堆檔案中的位置）【31】。在SQL Server中，可以為每個表指定一個聚集索引【32】。
 

diff --git a/zh-tw/ch6.md b/zh-tw/ch6.md
@@ -192,7 +192,7 @@
 
 	也許你想知道為什麼我們不使用 ***取模（mod）***（許多程式語言中的％運算子）。例如，`hash(key) mod 10`會返回一個介於0和9之間的數字（如果我們將雜湊寫為十進位制數，雜湊模10將是最後一個數字）。如果我們有10個節點，編號為0到9，這似乎是將每個鍵分配給一個節點的簡單方法。
 
-	模N（$mod N$）方法的問題是，如果節點數量N發生變化，大多數金鑰將需要從一個節點移動到另一個節點。例如，假設$hash(key)=123456$。如果最初有10個節點，那麼這個鍵一開始放在節點6上（因為$123456\ mod\  10 = 6$）。當您增長到11個節點時，金鑰需要移動到節點3（$123456\ mod\ 11 = 3$），當您增長到12個節點時，需要移動到節點0（$123456\ mod\ 12 = 0$）。這種頻繁的舉動使得重新平衡過於昂貴。
+	模N（$mod N$）方法的問題是，如果節點數量N發生變化，大多數鍵將需要從一個節點移動到另一個節點。例如，假設$hash(key)=123456$。如果最初有10個節點，那麼這個鍵一開始放在節點6上（因為$123456\ mod\  10 = 6$）。當您增長到11個節點時，鍵需要移動到節點3（$123456\ mod\ 11 = 3$），當您增長到12個節點時，需要移動到節點0（$123456\ mod\ 12 = 0$）。這種頻繁的舉動使得重新平衡過於昂貴。
 
 	我們需要一種只移動必需資料的方法。