在處理基於 WordPress 的專案時,可以說部署中最令人沮喪或最乏味的方面之一實際上是使環境中的資料庫彼此同步。
當然,在開發中使用測試數據、在暫存中使用用戶數據以及在生產中使用實際數據是有道理的,但沒有什麼靈丹妙藥,對吧?這意味著測試資料有時會起作用;其他時候則不會。
例如,假設您繼承了一個項目,您必須為其拉取資料庫,然後開始使用現有資料。或者假設您必須將整個網站或應用程式從一台伺服器遷移到另一台伺服器。
在這種情況下,測試數據並沒有太大幫助。相反,您需要一個工具。當然,WordPress 導入器對於基本遷移來說是一個不錯的工具,如果您熟悉資料庫前端並使用 SQL 本身,那麼執行 SQL 匯出和匯入是可以的。
但是那些介於兩者之間的人呢?
事實是,當涉及到 WordPress 資料庫遷移時,這是一個魚龍混雜的情況,因為我們中的許多人的技能水平因我們最常使用的堆疊的哪一部分而異。
我的意思是:
這並不是說沒有全端開發人員。顯然,有;然而,並不是每個人都處於這個位置。
因此,當涉及到遷移 WordPress 資料庫時,有些人的處境比其他人困難得多。或者,儘管人們對 SQL 很熟悉,但有些人可能只是在尋找一種工具來幫助簡化整個過程。
在本系列中,我們將介紹一個能夠實現此目的的實用程序,但在此之前,讓我們快速了解一下 WordPress 資料庫,以確保我們能夠都在同一頁上。
當談到討論 WordPress 資料庫時,可以寫一整系列的文章來討論每個表格、每個欄位、架構、如何寫最佳查詢等等。
這不是一個系列。
相反,我們將在本文中做兩件事:
最終,這應該有助於為那些在前端花費更多時間的人解釋或揭開一些底層工作的神秘面紗,並可能幫助那些花更多時間在應用程式層使用WordPress API 的人了解哪些功能會匹配到哪個表(這最終可以編寫更好的程式碼)。
總的來說,我想Wptuts 的大多數讀者都知道什麼是資料庫。
直接來自維基百科:
資料庫是有組織的資料集合。這些數據通常被組織為對現實的相關方面進行建模(例如,酒店房間的可用性),以支援需要此資訊的流程(例如,查找有空房的酒店)。
這是一個公平的定義,但我認為它不能很好地說明 WordPress 資料庫或類似的 Web 應用程式 - 它有點太籠統了。因此,從這裡開始,讓我們創建自己的工作定義,以便在本系列的其餘部分中使用。
#讓我們試試這個:
資料庫至少由一張表組成。表由行和列組成,每行儲存唯一的資訊。每行稱為一筆記錄。一個資料庫中可以存在多個表,有時表之間可以相互關聯。
也許我上面分享的內容中最令人困惑的部分是表格可以相互關聯。我們將在文章結束之前重新討論這個想法 - 但首先,讓我們討論一下 WordPress 資料庫。
簡而言之,WordPress 資料庫由 11 個表組成(除非您使用 Multisite,但這超出了本系列的範圍)。
現在,每個表還有自己的一組列,表示表中儲存的各種資訊。例如,wp_posts
表有一個名為 post_content
的列,它表示儲存在貼文中的實際內容。
表格及其說明如下:
這就是 WordPress 資料庫的全部內容。它相對簡單明了,對嗎?
貼文保存在貼文表中,評論保存在評論表中,用戶保存在用戶表中,等等。當然,有一些細微的差別(例如頁面儲存在 Posts 表中);然而,這是一個相對不複雜的模式。
這是一件好事。
另外,還記得我們之前提到過一些表格可以互相引用嗎?評論表和貼文表就是一個很好的例子。由於評論是在特定帖子上留下的,因此評論需要知道它與哪個帖子 ID 關聯,以便在加載帖子時,可以檢索與該帖子 ID 相關的評論。
#無論如何,這比我們在本系列中深入探討的細節要多,但希望這足以給您一個想法。如果您對更多技術資訊、表格之間的關係、列等感興趣,那麼請務必查看有關資料庫描述的 WordPress Codex 文章。
至此,我們已經涵蓋了 WordPress 資料庫入門知識中需要涵蓋的所有內容。希望這有助於揭開您在 WordPress 中保存資訊時幕後發生的事情的帷幕,但現在我們已經介紹了這一點,是時候看看一個可以使資料遷移變得極其簡單的工具了。
考慮到我們現在已經了解了資料庫的組織方式,我們也應該了解遷移的工作原理。
以上是遷移 WordPress 資料庫入門:基本資料庫知識的詳細內容。更多資訊請關注PHP中文網其他相關文章!