在新建表和數(shù)據(jù)倉庫時，往往需要做出許多決定。一些在當(dāng)時看起來似乎是無關(guān)緊要的決定，卻最終會導(dǎo)致你和你的客戶在使用數(shù)據(jù)庫的整個過程中飽嘗痛苦。

我們已經(jīng)和數(shù)千人以及他們的數(shù)據(jù)庫打過交道了，在經(jīng)歷了無數(shù)個小時的讀寫查詢之后，可以說我們幾乎見過所有的情況了。下面是我們總結(jié)出的有助于創(chuàng)建無痛模式（Schema）的10條規(guī)則。

1. 只使用小寫字母，數(shù)字和下劃線

不要在數(shù)據(jù)庫、模式、表格或者列名上使用點(diǎn)、空格或者破折號。因?yàn)辄c(diǎn)號是用來識別對象的，通常只在 database.schema.table.column 這種情況下使用。

在對象的名字中也包含點(diǎn)號會帶來困擾。同樣地，在對象名中使用空格將迫使你給查詢加入一堆不必要的引號：

另外，一旦在表格或者列名上使用了大寫字母，查詢就會變得更加難寫。因?yàn)槿绻慷际切懽帜傅脑挘藗兙蜎]有必要去特別記憶用戶表到底是Users還是users。

不僅如此，當(dāng)你最終變更數(shù)據(jù)庫或者將表復(fù)制到數(shù)據(jù)倉庫中時，除了一些數(shù)據(jù)庫以外，你無須記住哪個數(shù)據(jù)庫是大小寫敏感的。

2. 使用簡單且具有描述性的列名

如果users表需要定義一個引用了packages表的外鍵，那么將其命名為package_id是個不錯的選擇。我們應(yīng)該避免像是pkg_fk這樣的又短又含糊的列名，因?yàn)槠渌撕茈y知道那是什么意思。具有描述性的名字能夠使得其他人更容易理解模式，而且當(dāng)團(tuán)隊(duì)擴(kuò)大時這一點(diǎn)對于保持工作效率也是很重要的。

不要使用模棱兩可的名字命名可能有多種解釋方法的數(shù)據(jù)。如果你發(fā)現(xiàn)自己正在以item_type或item_value這樣的命名風(fēng)格創(chuàng)建列時，那么可能就說明你應(yīng)該使用更多的帶有具體名字的列了，像是photo_count、view_count和transaction_price。

因?yàn)檫@樣做的話，列中存儲了什么樣的數(shù)據(jù)總是可以由模式得知的，而并不需要由行中的其他值推導(dǎo)出來。

不要使用表名作為列名的前綴。因?yàn)橐话銇碚f在users表中定義諸如user_birthday、user_created_at或者user_name這樣的列名起不到什么輔助作用。

最后，還要避免將諸如column、tag或user這樣的保留關(guān)鍵字用作列名。因?yàn)橐坏┦褂昧吮Ａ絷P(guān)鍵字，就意味著不得不在查詢語句中使用額外的引用符，而當(dāng)有人忘記這么做的時候，數(shù)據(jù)庫就會產(chǎn)生非常令人困惑的錯誤信息。而且如果在本該是列名出現(xiàn)地方使用了關(guān)鍵字，那么數(shù)據(jù)庫就無法理解查詢語句。

3.使用簡單且具有描述性的表名

如果表名是由多個單詞組成的，那么請使用下劃線分割它們。因?yàn)閜ackage_deliveries要比packagedeliveries更容易讀。

如果可能的話，總是使用一個單詞而不是兩個，因?yàn)閐eliveries要更加容易閱讀。

不要用模式的名字作為表名的前綴。如果你需要將一些表劃入一個范圍，那么只需將這些表放入到一個模式中即可。和有前綴的列名一樣，諸如store_items、store_transactions或者store_coupons這樣的表名，通常都是不需要額外的前綴的。

我們推薦使用復(fù)數(shù)形式的名字為表命名（例如packages），并且對聯(lián)合表的表名中的兩個單詞也都使用復(fù)數(shù)形式。單數(shù)形式的表名更可能意外地與關(guān)鍵字沖突并且一般在查詢中其可讀性也不高。

4. 將整形作為主鍵

無論你是正在使用各種UUID（通用唯一識別碼）類型的列作為主鍵，還是你認(rèn)為加入帶有自增長整型序列的主鍵根本沒有意義（比如對于聯(lián)合表），我們都建議你添加一個帶有自增長整型序列的標(biāo)準(zhǔn)id列。這種類型的主鍵會使得特定的分析變得更加容易，比如從一組數(shù)據(jù)中只選出第一行。

并且當(dāng)導(dǎo)入數(shù)據(jù)的工作導(dǎo)致了數(shù)據(jù)的重復(fù)時，主鍵也會成為靈丹妙藥，因?yàn)槲覀兛梢酝ㄟ^主鍵輕松刪除特定的行：

避免多列主鍵。當(dāng)努力編寫高效的查詢時，多列主鍵將會導(dǎo)致查詢語句很難理解，并且很難修改。我們可以使用一個整型的主鍵，或者一個多列的唯一約束，再或者一些單列的索引來取代多列主鍵。

5. 與外鍵一致

命名主鍵和外鍵有許多種風(fēng)格。我們建議諸位使用的是最為普遍的風(fēng)格，即對于任意的表格foo，將foo中的主鍵命名為id，將所有的外鍵命名為foo_id。

另一種風(fēng)格是使用全局統(tǒng)一的主鍵名。在這種風(fēng)格下，表foo的主鍵稱為foo_id，而所有的外鍵也稱為foo_id。不過無論使用哪種風(fēng)格，使用縮寫的話（比如將users表縮寫為uid)，總是會造成困擾或名稱沖突，所以應(yīng)該避免使用縮寫。

而且，無論你選用了什么風(fēng)格，都要堅持下去。不要在某些地方使用uid，而又在其他地方使用user_id或者users_fk。

除此之外還要留意外鍵并不顯式匹配一張表的情況。一個名為owner_id的列可能是users表的一個外鍵，當(dāng)然也可能不是。因此如果有必要的話，請將作為外鍵的列命名為user_id或者owner_user_id。

6. 將日期時間存儲為各種日期時間類型

不要使用Unix的時間戳或者字符串來存儲日期，而是要將它們轉(zhuǎn)換為各種日期時間類型。雖然SQL的日期計算函數(shù)并不是最棒的，但是調(diào)用這些函數(shù)來處理時間戳總比自己來處理要簡單。在查詢時，我們需要為每一個涉及到從timestamp到datetime類型的轉(zhuǎn)換的查詢調(diào)用SQL的日期函數(shù)。

不要將年、月、日分別存儲到不同的列中。因?yàn)檫@樣會導(dǎo)致每個有關(guān)時間序列的查詢都更加難寫，而且也會在使用這張表的日期信息時給大多數(shù)的SQL初學(xué)者造成障礙。

7. 總是使用UTC

使用時區(qū)而不是UTC將導(dǎo)致無窮無盡的問題。好的工具（包括我們的Periscope）擁有你所需要的從UTC轉(zhuǎn)換為你所在時區(qū)數(shù)據(jù)的所有功能。在Periscope中，簡單地加個:pst就可以將UTC轉(zhuǎn)換為太平洋時間。

應(yīng)該將數(shù)據(jù)庫的時區(qū)設(shè)為UTC，并且所有datetime的列都應(yīng)該是剝離時區(qū)后的類型（如，無時區(qū)的timestamp）。

如果你的數(shù)據(jù)庫的時區(qū)不是UTC，或者你的數(shù)據(jù)庫混合了UTC和非UTC時間日期，那么時間序列的分析查詢將會變得更加困難。

8.單一的真相源

一塊數(shù)據(jù)應(yīng)該只有單一的真相源（Source of Truth）。視圖和匯總（Rollup）本身應(yīng)該有所標(biāo)示。這樣做的話，數(shù)據(jù)的消費(fèi)者就會知道他們使用的數(shù)據(jù)和原生真相之間的區(qū)別。

另一方面，將諸如user_id、user_id_old或者user_id_v2的遺留列都保留的話，只會帶來無盡的困擾。因此請確保在日常維護(hù)中會進(jìn)行刪除廢棄的表格和不再使用的字段的工作。

9.優(yōu)先使用沒有JSON列的表格

請不要使用列過多的表。如果一張表有超過幾十個列并且其中一些是以序列命名（例如，answer1、answer2、answer3）的話，那么馬上你就會感到不好過了。

正確的做法是將這樣的表轉(zhuǎn)化為不包含重復(fù)列的模式，因?yàn)檫@樣的模式將很容易查詢。例如，在一個查詢中計算某個調(diào)查表中已完成的題目的數(shù)目：

對于查詢分析而言，從JSON列抽出數(shù)據(jù)的操作將大幅降低查詢的性能。雖然有很多很棒的理由支持我們在產(chǎn)品中使用JSON列，但是對于查詢分析來說并不是這樣。大膽得將JSON列拆解為更簡單數(shù)據(jù)類型，可以使查詢分析變得更快更容易。

10.不要過度規(guī)范化

日期，郵編和國家不需要使用帶有外鍵查詢的表單獨(dú)存放。過度地規(guī)范化將會導(dǎo)致每個查詢后面都要帶上一些相同的表連接操作。這樣不但創(chuàng)建了許多重復(fù)的SQL，而且數(shù)據(jù)庫為此還要做很多額外的工作。

表是數(shù)據(jù)庫中的一等對象，擁有很多屬于自己的數(shù)據(jù)。其余的任何數(shù)據(jù)都可以作為另一個更重要對象的附加列。