課堂

1.1 簡介 設計數據庫有點類似於設計 Java 項目的架構。您可以將所有數據放在幾個表中，或者您可以從模式和數十個表構建一個漂亮的數據結構。 以下是開發人員在設計數據庫時通常面臨的任務： 確保所有必要的信息都存儲在數據庫中。 確保獲得有關所有必要請求的數據的可能性。 減少數據的冗餘和重複。 確保數據庫完整性 數據訪問速度優化 要記住的主要事情是你不能建立一個理想的數據庫結構，因為。它和您的代碼一樣，也會不斷變化。設計數據庫結構時應牢記三點： 結構必須足夠好。 凡事必有其人能

2.1. 概念設計 數據庫設計分三個階段進行： 概念設計; 邏輯設計； 物理設計。 概念設計階段的目的是根據用戶對主題領域的想法創建概念數據模型。為了實現它，執行了一系列順序程序。實體（概念）模式的示例： 1. 實體及其文檔的定義。為了識別實體，定義了獨立於其他對象存在的對象。這些對像是實體。每個實體都被賦予了一個用戶可以理解的有意義的名稱。實體的名稱和描述被輸入到數據字典中。如果可能，設置每個實體的預期實例數。 2. 確定實體及其文檔之間的關係。只定義滿足數據庫設計要求所必

3.1 數據庫規範化 範式是關係數據模型中關係的一種屬性，它在冗餘方面對其進行了表徵，可能導致採樣或更改數據的邏輯錯誤結果。範式被定義為關係（數據庫中的表）必須滿足的一組要求。 將數據庫關係轉換為符合規範形式的形式的過程稱為規範化。規範化旨在使數據庫的結構成為提供最小邏輯冗餘的形式，而不是為了降低或提高性能，或者減少或增加數據庫的物理量。 規範化的最終目標是減少存儲在數據庫中的信息的潛在不一致性。歸一化過程的一般目的如下： 排除某些類型的冗餘； 修復一些更新異常； 開發一個足

4.1 簡介 通過將數據庫表轉換為常規表，您現在可以分析它們之間的關係。兩個相關表之間交互的元素數稱為基數。基數可幫助您控制將數據分區到表中的效率。 從理論上講，所有實體之間都可以保持相互關係，但在實踐中，實體之間存在三種類型的關係： 一對一 一對多 多對多 4.2 一對一溝通 如果對於實體 B 的每個實例只有一個實體 A 的實例，則稱它們具有一對一的關係（通常表示為“1:1”）。在 ER 圖上，這種關係由兩端各有一個小條的線表示： 1:1 關係通常表示，除非您有充分的理由將

5.1 簡介 Internet 上充斥著關於應如何在關係數據庫中選擇和使用鍵的教條式規則。有時爭論甚至會演化為 holivars：應該使用自然密鑰還是人工密鑰？自動遞增整數或 UUID？ 在閱讀了 64 篇文章，翻閱了 5 本書的章節，並在 IRC 和 StackOverflow 上提出了大量問題之後，我（Joe “begriffs” Nelson，原文章的作者）似乎已經把拼圖的各個部分放在一起並且現在可以調和對手。很多關鍵性的爭論其實都是因為誤解了別人的觀點而產生的。 讓我

6.1 簡介 現在讓我們從理論轉向實踐。 “從理論上講，理論和實踐之間沒有區別。實際上，他們是。” 我們生活在現實世界中，所有的軟件產品最終都是為活著的人創造的。這些活著的人對加載緩慢的網站和運行緩慢的程序感到非常惱火。 而如果一個數據庫查詢花費的時間超過一秒，這是不可接受的。用戶根本不會使用頁面/功能如此緩慢的產品。 但通常，為了顯示一個頁面，您需要對數據庫執行幾十次查詢。如果它們是按順序執行的，那麼您將不再有第二個限制，但假設每個請求 100 毫秒。 以下是程序員加速數據

7.1 DB端緩存 MySQL 在處理表時使用高度可擴展的算法，因此即使使用少量內存也可以運行 MySQL。當然，為了獲得更好的性能，您需要更多的 RAM。 要查看當前設置，請連接到數據庫

8.1 為什麼需要反規範化？ 大表之間計算量最大的操作是連接。因此，如果在一個查詢中需要“通風”幾個由數百萬行組成的表，那麼 DBMS 將花費大量時間進行此類處理。 此時用戶可以移開去喝咖啡。處理的交互性幾乎消失，接近批處理的交互性。更糟糕的是，在批處理模式下，用戶在早上收到前一天請求的所有數據，並冷靜地處理它們，為晚上準備新的請求。 為了避免大量連接的情況，表被非規範化。但無論如何都不是。有一些規則允許您根據為數據倉庫構建表的規則將事務非規範化表視為“規範化”。 在分析處理