Waterline：SQL/noSQL 資料對應器 (ORM/ODM)
Sails 內建一個強大的 ORM/ODM，稱為 Waterline。Waterline 是一個與資料儲存庫無關的工具，可大幅簡化與一個或多個資料庫的互動。它在底層資料庫之上提供了一個抽象層，讓您能夠輕鬆查詢和操作資料，無需編寫特定於供應商的整合程式碼。
資料庫不可知論
在結構化資料庫（如 Postgres、Oracle 和 MySQL）中，模型以表格表示。在 MongoDB 中，它們以 Mongo「集合」表示。在 Redis 中，它們使用鍵/值對表示。每個資料庫都有自己獨特的查詢語法，在某些情況下，甚至需要安裝和編譯特定的原生模組才能連接到伺服器。這涉及相當多的額外開銷，並帶來令人不安的 供應商鎖定 到特定資料庫的程度；例如，如果您的應用程式使用大量 SQL 查詢，則稍後將很難切換到 Mongo 或 Redis，反之亦然。
Waterline 查詢語法超越了所有這些，專注於業務邏輯，例如建立新記錄、獲取/搜尋現有記錄、更新記錄或銷毀記錄。無論您聯繫的是哪個資料庫，使用方式都完全相同。此外，Waterline 允許您 .populate() 模型之間的關聯，即使每個模型的資料都位於不同的資料庫中。這表示您可以將應用程式的模型從 Mongo 切換到 PostgreSQL、MySQL，然後再切換回來，而只需進行最少的程式碼變更。對於需要低階、特定於資料庫的功能的情況，Waterline 提供了一個查詢介面，讓您可以直接與模型的底層資料庫驅動程式對話（請參閱 .query() 和 .native()）。
情境
讓我們想像一下，您正在建立一個電子商務網站，並附帶一個行動應用程式。使用者依類別瀏覽產品或依關鍵字搜尋產品，然後購買它們。就這樣！您的應用程式的某些部分非常普通：您有一個 API 驅動的流程，用於登入、註冊、訂單/付款處理、重設密碼等。但是，您知道您的路線圖中潛藏著一些平凡的功能，這些功能可能會變得更加複雜。果然
彈性
您詢問業務部門他們想要使用哪個資料庫
「資料庫... 什麼？我們別急，不希望做出錯誤的選擇。我會讓營運/IT 部門處理。你們先開始吧。」
為 Web 應用程式/API 選擇單一資料庫的傳統方法實際上對於某些生產用例來說是受限的。雖然大多數應用程式可以使用一種資料庫，但有些應用程式需要維持與現有資料集的相容性，或者（如果您正在處理高流量的生產應用程式）為了效能原因而使用多種類型的資料庫。
由於 Sails 預設使用 sails-disk，因此您可以使用零配置開始建構應用程式，使用本機暫存檔作為儲存空間。當您準備好切換到真實環境（並且當每個人都知道那是什麼時），只需變更應用程式的 資料儲存庫配置。
相容性
產品負責人/利害關係人走向您並說
「喔，順便一提，產品實際上已經在我們的銷售點系統中上線了。我猜那是一些 ERP 系統，類似「DB2」之類的東西？總之，我相信你會搞定的。聽起來很簡單，對吧？」
許多企業應用程式必須與現有資料庫整合。如果您幸運的話，一次性的資料遷移可能就足夠了，但更常見的是，現有資料集仍在被其他應用程式修改。為了建構您的應用程式，您可能需要整合來自多個舊系統的資料，或與儲存在其他地方的獨立資料集整合。這些資料集可能位於分散在世界各地的五個不同的伺服器上！一個共置的資料庫伺服器可能託管一個具有關聯式資料的 SQL 資料庫，而另一個雲端伺服器可能託管一些 Mongo 或 Redis 集合。
Sails/Waterline 讓您可以將不同的模型連接到不同的資料儲存庫，無論是在本機還是在網際網路上的任何地方。您可以建構一個 User 模型，該模型對應到舊版資料庫中的自訂 MySQL 表格（具有奇怪的欄位名稱）。Product 模型也是如此，它對應到 DB2 中的表格，或者 Order 模型對應到 MongoDB 集合。最棒的是，您可以跨這些不同的資料儲存庫和轉接器進行 .populate()，因此如果您將模型配置為位於不同的資料庫中，則您的控制器/模型程式碼不需要變更（請注意，您將需要手動遷移任何重要的生產資料）。
效能
您深夜坐在筆記型電腦前，意識到
「我該如何進行關鍵字搜尋？產品資料沒有任何關鍵字，而且業務部門希望搜尋結果根據 n-gram 詞序進行排名。而且我不知道這個推薦引擎將如何運作。而且如果我今晚再聽到一次
大數據這個詞，我就要辭職回咖啡店工作了。」
那麼「大數據」呢？通常，當您聽到部落客和分析師使用這個流行語時，您會想到資料探勘和商業智慧。您可能會想像一個從多個來源提取資料、處理/索引/分析資料，然後將提取的資訊寫入其他地方，並保留原始資料或丟棄它的過程。
但是，有一些更常見的挑戰也適用於相同的索引/分析需求：例如，「駕駛方向鄰近度」搜尋或相關產品的推薦引擎等功能。幸運的是，許多資料庫簡化了特定的大數據用例。例如，MongoDB 提供地理空間索引，而 ElasticSearch 為全文檢索資料索引提供了出色的支援。
以它們預期的方式使用資料庫可以帶來巨大的效能優勢，尤其是在複雜的報告查詢、搜尋（實際上只是自訂排序）和 NLP/機器學習方面。某些資料庫非常擅長回答傳統的關聯式業務查詢，而另一些資料庫更適合用於資料的 map/reduce 樣式處理，在閃電般的讀取/寫入方面都具有最佳化和權衡。當應用程式的使用者群擴大時，這種考量尤其重要。
轉接器
與大多數 MVC 框架一樣，Sails 支援 多個資料庫。這表示無論我們使用的是 MongoDB、MySQL 還是任何其他支援的資料庫，查詢和操作資料的語法始終相同。
Waterline 透過其轉接器概念在此彈性基礎上構建。轉接器是一小段程式碼，可將 find() 和 create() 等方法對應到較低階的語法，例如 SELECT * FROM 和 INSERT INTO。Sails 核心團隊維護一些 最受歡迎的資料庫 的開放原始碼轉接器，並且還有大量的 社群轉接器 可用。
實際上，自訂 Waterline 轉接器 非常容易建構，並且可以實現更易於維護的整合：從專有的企業帳戶系統到快取，再到傳統資料庫，應有盡有。
資料儲存庫
資料儲存庫 代表特定的資料庫配置。此配置物件包括要使用的轉接器，以及主機、連接埠、使用者名稱、密碼等資訊。資料儲存庫在 Sails 配置 config/datastores.js 中定義。
// in config/datastores.js
// ...
{
adapter: 'sails-mysql',
host: 'localhost',
port: 3306,
user: 'root',
password: 'g3tInCr4zee&stUfF',
database: 'database-name'
}
// ...
類比
想像一下一個檔案櫃，裡面裝滿了已完成的鋼筆墨水表格。所有表格都具有相同的欄位（例如「姓名」、「出生日期」、「婚姻狀況」），但對於每個表格，欄位中寫入的值都不同。例如，一個表格可能包含「Lara」、「2000-03-16T21:16:15.127Z」、「單身」，而另一個表格包含「Larry」、「1974-01-16T21:16:15.127Z」、「已婚」。
現在想像一下您經營一家熱狗店。如果您非常有條理，您可能會按以下方式設定檔案櫃
- 員工（包含您的員工記錄）
fullNamehourlyWagephoneNumber
- 地點（包含您經營的每個地點的記錄）
streetAddresscitystatezipcodepurchases- 在此地點進行的所有購買的清單
manager- 管理此地點的員工
- 購買（包含您的客戶進行的每筆購買的記錄）
madeAtLocationproductsPurchasedcreatedAt
- 產品（包含您的各種產品供應的記錄）
nameOnMenupricenumCaloriespercentRealMeatavailableAt- 提供此產品供應的地點清單。
在您的 Sails 應用程式中，模型就像其中一個檔案櫃。它包含記錄，記錄就像表格。屬性就像每個表格中的欄位。
注意事項
- 如果您覆寫內建的 ORM Waterline，則本模型文件不適用。在這種情況下，您的模型將遵循您設定的任何慣例，以及您正在使用的任何 ORM 程式庫（例如 Mongoose）。
為了在 sailsjs.com 上獲得更好的體驗，更新您的瀏覽器。
概念
用心建構
Sails 框架由德克薩斯州奧斯汀的一家 Web & 行動商店 建構，並在我們的貢獻者的幫助下完成。我們在 2012 年創建 Sails，以協助我們進行 Node.js 專案。自然而然地，我們將其開源。我們希望它能讓您的生活更輕鬆一點！
© 2012-2024 The Sails Company.
Sails 框架是免費且開源的，基於 MIT 許可證.
插圖由 Edamame 提供。