託管資料庫

這是什麼

託管資料庫是存放應用所需記住的一切的儲存層——客戶、預約、訂單、庫存、訊息。在 ybuild 上，它隨你的應用自動開通，接進後端，並由平台為你維護。你永遠不用碰連線字串，也不用另外架設一個服務。

為什麼重要

一套執行中的業務系統，其真實程度取決於背後的資料。遺失記錄，或把記錄散落在需要你自己拼接的各種工具裡，毀掉的是業務，而不只是應用。一個有備份、始終可用的託管資料庫，才能讓這套系統被真正託付給實際工作。

在 ybuild 上怎麼用

當 ybuild 建置你的應用時，它會依你的提示詞設計資料庫結構，並在同一趟過程中把它開通在平台上。上線的應用直接對它讀寫——託管在 ybuild 上，透過你自己的網域對外服務——備份在背景默默執行。用日常語言要求新增一個欄位或一張表，ybuild 會為你遷移資料。

ybuild 開通資料庫時會建置什麼

當你描述應用該記住什麼時，ybuild 會完成一位資料庫工程師本要手工做的工作。它讀取你提示詞裡的名詞——客戶、預約、發票、產品——把它們變成一套真正的關聯式結構：為每一種記錄建一張表，帶型別的欄位（價格是數字，預約時間是時間戳記，電子郵件是帶唯一性規則的文字），主鍵讓每一列都有穩定的身分，外鍵把本該關聯的記錄連在一起，於是一筆訂單指回下單的客戶，一個訂單明細指回它所屬的訂單。

這套結構正是資料庫與試算表的區別所在。關聯讓應用能回答真實的問題——這位客戶所有未付的發票，下週二的每一個預約——而不用你逐列翻查。在你用來檢索的欄位上建立索引，讓這些查詢在一張表從五十列長到五萬列時依然快速。限制條件把壞資料擋在門外：你無法儲存一筆沒有客戶的訂單，也無法在同一個電子郵件下建兩個帳號，於是幾個月後業務還在執行時，記錄依然可信。

ybuild 把它開通在平台上，接進你應用的後端，並把憑證當作託管密鑰保管——你永遠看不到、也不用貼上任何連線字串。跑在你自己網域上的應用直接對它讀寫。當你之後說「給客戶加一個點數欄位」或「給每次預約記一筆訂金」時，ybuild 會產生遷移，套用到執行中的資料庫上，並保留每一列既有資料。結構隨業務演進，而不是在第一天就被凍結。

自己搭建 vs 在 ybuild 上獲得

手工架起一個生產級資料庫本身就是一個專案。你要挑選引擎與版本，開通一個執行個體，規劃它的記憶體與儲存空間，鎖定網路與防火牆規則，產生並輪替憑證，還要設定連線集區，好讓一波突發流量不會耗盡連線。然後你還得把遷移工具接進部署流程，讓結構變更不會破壞線上資料。這些做完，還沒為你的客戶交付任何一個功能。

真正的代價在上線之後。一個自管資料庫讓你成了隨叫隨到的管理員：打安全修補程式、盯著磁碟被塞滿、調校慢查詢、為某個節點當機時的容錯移轉做預案，還有那件人人都低估的事——執行並測試備份。雲端服務商對託管服務的定義，恰恰就是替你接管設定、維護、每日備份與自動容錯移轉，而他們引用的研究把擺脫自管基礎架構的五年報酬率算到了 400% 以上，主要是因為團隊不再把一週週的時間花在資料庫的雜務上。

在 ybuild 上沒有單獨的步驟，也沒有單獨的帳單。資料庫在建置你應用的同一趟裡被設計並開通，由平台打修補程式與備份，就託管在執行中的應用旁邊、跑在你自己的網域上。你永遠不用去註冊一個資料庫服務、接入連線字串，或對著第二個主控台去核對。當應用變化時，資料層隨之變化——你用日常語言描述想要的結果，平台在底層處理好結構、遷移與維護。

備份、還原與鮮活的資料

對一門真實的生意來說，資料庫就是這門生意本身。它是你很難重建的客戶名單，是你的會計需要的訂單歷史，是你在法律上要負責的病患或客戶記錄。最傷人的故障並不是戲劇性的當機——而是一次糟糕的批次編輯、一次誤刪，或一次有 bug 的匯入在客戶照常使用應用時悄悄覆寫了好資料。這就是為什麼單靠每晚一次的匯出還不夠。

大平台給自己定的標準是時間點還原：不是只能還原到昨晚的快照，而是持續備份把資料庫的交易記錄檔串流記錄下來，讓你能倒回到某個具體時刻。AWS 的文件寫明可以精確到一秒、最遠回溯 35 天來還原，Google 的託管服務則把自動備份保留最長一年。這個承諾落到實處很簡單——如果下午 2:14 有東西破壞了你的資料，你能拿回 2:13 時的狀態。ybuild 把備份當作平台的一部分跑在你的資料庫上，於是從一次失誤中還原是產品自帶的能力，而不是一張你送出後只能乾等的支援工單。

有幾件事一個人做很容易出錯，而平台替你處理好了。一份你從沒還原過的備份，算不上真正的備份——還原必須被演練，而不能只是假設。對一張線上表做結構遷移，必須在不把客戶鎖在交易中途之外的前提下完成。而把資料放在同一個系統裡、緊挨著用它的應用，正是阻止你一步步滑向五張半同步試算表的關鍵。因為你的資料就在 ybuild 上、和應用一起存放與執行——跑在你自己的網域上——它始終是一套連貫、可還原的系統，隨業務成長，而不是變成一堆你在默默背負責任的儲存。

常見問題

我應用的資料到底存在哪裡？

存在 ybuild 上。資料庫在建置你應用的同一趟裡開通在平台上，接進後端，並和應用一起透過你自己的網域對外服務。沒有單獨的資料庫服務要去註冊，也沒有連線字串要你來管理。

它是真正的資料庫，還是幕後只是一張試算表？

它是一個真正的關聯式資料庫——規規矩矩的表、帶型別的欄位、主鍵，以及把本該關聯的記錄連起來的關聯，比如一筆訂單連到下單的客戶。ybuild 依你的提示詞設計這套結構，於是應用能回答關於你資料的真實問題，而不是逐列翻查。

我之後能改變應用存什麼，又不遺失資料嗎？

可以。用日常語言要求一個新欄位、新表或新關聯——「給每次預約記一筆訂金」——ybuild 會在執行中的資料庫上產生並執行遷移，保留每一列既有資料。結構隨業務成長，而不是在第一天就被固定。

我的記錄有備份嗎，出了錯能還原嗎？

能。ybuild 把備份當作平台的一部分跑在你的資料庫上，於是一次糟糕的編輯、一次誤刪，或一次壞掉的匯入，都不代表資料就此消失。還原內建於產品之中、由 ybuild 提供，而不是一次你得自己去搭的手工還原。

隨著業務成長，資料庫會怎樣？

它由平台為你託管。當你從幾十筆記錄長到幾萬筆，平台在底層處理好開通、修補與擴縮——正是一位專職資料庫管理員會做的工作——於是應用在你自己的網域上始終保持快速，而你無需手工調校或擴容。