[[199956]]

剛做開(kāi)發(fā)人員的時(shí)候，需要掌握的東西非常多。首先是編程語(yǔ)言本身，還有所有你用到的框架的的特定用法，之后(也可能是之前)，前端開(kāi)發(fā)的東西也會(huì)混進(jìn)來(lái)，在開(kāi)發(fā)過(guò)程中你還要考慮數(shù)據(jù)存在哪的問(wèn)題。

起初，由于你有太多東西需要迅速掌握，在應(yīng)用設(shè)計(jì)的過(guò)程中，會(huì)傾向于把數(shù)據(jù)庫(kù)放在后面考慮(大概因?yàn)樗鼘?duì)用戶的使用體驗(yàn)沒(méi)什么影響)。結(jié)果就是在處理數(shù)據(jù)庫(kù)的時(shí)候，會(huì)發(fā)現(xiàn)很多不好的實(shí)踐。這里舉幾個(gè)例子。

1. Storing images 儲(chǔ)存圖片

數(shù)據(jù)庫(kù)里不應(yīng)該放圖片。你可以做的事情并不代表你就應(yīng)該去做。圖片會(huì)占用數(shù)據(jù)庫(kù)里相當(dāng)大的空間，吃掉不必要的 IO 資源從而拖慢應(yīng)用。這個(gè)錯(cuò)誤最常出現(xiàn)的情況，就是新人將圖片用 base64 編碼，然后將其儲(chǔ)存在很大的 text/blob 字段當(dāng)中。

更好的辦法是直接將圖片上傳至像 Amazon S3 這樣的云服務(wù)上，然后用數(shù)據(jù)庫(kù)里用 text 字段儲(chǔ)存圖片的 URL。每次要加載一張圖片的時(shí)候，只要把圖片的 URL 輸出到有效的 <img> 標(biāo)簽里就可以了。這會(huì)極大地提升網(wǎng)頁(yè)的響應(yīng)速度，對(duì)大規(guī)模 Web 應(yīng)用非常有幫助。

2. Limit/Offset

分頁(yè)在很多應(yīng)用中都非常常見(jiàn)。從你開(kāi)始學(xué)習(xí) SQL，(你就該知道)最直接的分頁(yè)方法就是先用 ORDER BY 對(duì)數(shù)據(jù)庫(kù)的一些列進(jìn)行排序，然后 LIMIT 返回的結(jié)果數(shù)，對(duì)除***頁(yè)外的每一頁(yè)使用 OFFSET。這看起來(lái)很符合邏輯，直到你處理中等規(guī)模應(yīng)用時(shí)才意識(shí)到：

1. 它對(duì)數(shù)據(jù)庫(kù)施加的負(fù)載是非常痛苦的。
2. 它具有不確定性，記錄應(yīng)該隨著用戶翻頁(yè)而改變。

不幸的是：分頁(yè)非常復(fù)雜，目前還沒(méi)有一個(gè)萬(wàn)全之策。

3. 用整數(shù)做 primary key

在創(chuàng)建 primary key 的時(shí)候，幾乎所有的 ORM(Object Relational Mapping 對(duì)象關(guān)系映射)的默認(rèn)做法都是創(chuàng)建一個(gè)串行字段，它是按順序自動(dòng)生成的，然后你就可以用它(這些自動(dòng)生成的數(shù)字)作為你的 primary key。在管理員看來(lái)，這是非常直觀的，因?yàn)榭梢杂捎脩?1 到 用戶 2 這樣依次查看。對(duì)大多數(shù)的應(yīng)用來(lái)說(shuō)，這種做法通常是不錯(cuò)的。但是隨著這些整數(shù) primary key 不斷變大，你很快就會(huì)意識(shí)到處理他們會(huì)讓人筋疲力盡。對(duì)于大規(guī)模系統(tǒng)，這是很不理想的處理方法。此外，你還會(huì)依賴生成這些 key 的那個(gè)系統(tǒng)，在你必須要擴(kuò)大規(guī)模的時(shí)候，會(huì)非常痛苦。更好的解決辦法是從一開(kāi)始就利用好 UUID (Universally Unique Identifier 通用唯一識(shí)別碼)的優(yōu)勢(shì)。

(UUID)還有其它的好處，那就是它不會(huì)無(wú)形中暴露給用戶(數(shù)據(jù)庫(kù)中)有多少用戶、列表、或是這些 key 所指代的任何東西。

4. 新列中的默認(rèn)值

無(wú)論你做這個(gè)工作有多久，都不會(huì)一次就創(chuàng)建出一個(gè)***的 schema。***是將數(shù)據(jù)庫(kù) schema 視為一個(gè)持續(xù)演化的文檔。不幸的是：向數(shù)據(jù)庫(kù)中添加一列是件很容易的事，這也就意味著在添加列的時(shí)候把工作搞砸同樣很容易。默認(rèn)情況下，如果你新添加了一列，通常是允許有 NULL 值的。這個(gè)操作速度很快，但大多數(shù)應(yīng)用實(shí)際上不太想讓他們的數(shù)據(jù)里有 null 值，他們會(huì)想要設(shè)置默認(rèn)值。

如果你在表里添加設(shè)置了默認(rèn)值的新列，會(huì)對(duì)這張表觸發(fā)一次完全的重寫。注意：這對(duì)應(yīng)用中的任何(數(shù)據(jù)量)很大的表都非常不利。(正確的方法)恰恰相反，***是先允許 null 值存在，這樣操作就是即時(shí)的，接下來(lái)再設(shè)置默認(rèn)值，再用后臺(tái)進(jìn)程去回溯更新數(shù)據(jù)。

實(shí)際操作比我所說(shuō)的要更復(fù)雜，幸好已經(jīng)有一些便利的指南可以為我們提供幫助。

5. 過(guò)度標(biāo)準(zhǔn)化

開(kāi)始學(xué)習(xí)數(shù)據(jù)庫(kù)的標(biāo)準(zhǔn)化的時(shí)候，(標(biāo)準(zhǔn)化)感覺(jué)就像是很正確的事。你創(chuàng)建了一個(gè) posts 的表，里面包含 authors，每篇文章(post)都屬于一個(gè)條目(category)，所以你又創(chuàng)建了一個(gè) categories 的表，然后再創(chuàng)建一個(gè)把它們倆 join 在一起的表，post_categories。從根本上來(lái)說(shuō)，這樣做標(biāo)準(zhǔn)化也沒(méi)什么原則上的錯(cuò)誤，但是某種程度上，標(biāo)準(zhǔn)化的收益正在遞減。

在上述實(shí)例中，categories 可以簡(jiǎn)單地作為 post 里的一個(gè) varchar 字段。標(biāo)準(zhǔn)化是件很有意義的工作，但是每次處理包含多對(duì)多關(guān)系的表時(shí)都要深思熟慮，想想你是不是真的需要在關(guān)系的兩邊都各用一個(gè)單獨(dú)的表。

修正：值得一提的是，欠標(biāo)準(zhǔn)化也是個(gè)問(wèn)題。這里并不存在“一刀切”的解決方案。有時(shí)完全不做標(biāo)準(zhǔn)化和完全標(biāo)準(zhǔn)化也行得通。像 @fuzzychef 說(shuō)的那樣：“適度標(biāo)準(zhǔn)化，即金發(fā)姑娘原則(The goldilocks principle，意為適度的是***的)”。

總結(jié)

在 Twitter 上問(wèn)到這個(gè)問(wèn)題的時(shí)候，我得到了很多非常棒的回應(yīng)，但是這些回應(yīng)五花八門。從“從不查看 ORM 生成的查詢”這樣的基本問(wèn)題，到像事務(wù)隔離這樣的進(jìn)階話題。有一點(diǎn)我并沒(méi)提到，但是對(duì)于所有構(gòu)建 app 的人來(lái)說(shuō)都非常值得注意的一點(diǎn)就是索引。了解索引的工作原理，知道你需要?jiǎng)?chuàng)建什么樣的索引，是獲得良好的數(shù)據(jù)庫(kù)性能的關(guān)鍵。除了用 Postgres 分析性能的實(shí)踐步驟以外，還有很多關(guān)于索引的基礎(chǔ)知識(shí)的文章。

通常我會(huì)鼓勵(lì)大家把數(shù)據(jù)庫(kù)當(dāng)做你工具箱中的另一個(gè)工具，而不是什么非學(xué)不可的惡魔。但我希望，以上的提示可以幫助初學(xué)者避免一些基本錯(cuò)誤。