Waterline: SQL/noSQL データマッパー (ORM/ODM)
Sailsには、ORM/ODM と呼ばれる強力な Waterline がインストールされています。これは、1つ以上のデータベースとの相互作用を劇的に簡素化する、データストアに依存しないツールです。基盤となるデータベースの上に抽象化レイヤーを提供し、ベンダー固有の統合コードを書かずにデータを簡単にクエリおよび操作できます。
データベース非依存性
Postgres、Oracle、MySQL などのスキーマフルデータベースでは、モデルはテーブルで表されます。MongoDB では、Mongo「コレクション」で表されます。Redis では、キーと値のペアを使用して表されます。各データベースには、独自のクエリ方言があり、場合によっては、サーバーに接続するために特定のネイティブモジュールをインストールしてコンパイルする必要があります。これにはかなりのオーバーヘッドが伴い、特定のデータベースへの不安定なレベルのベンダーロックインが発生します。たとえば、アプリで多数のSQLクエリを使用している場合、後でMongoやRedisに切り替えるのは非常に困難であり、その逆も同様です。
Waterlineクエリ構文は、それらすべてを抽象化し、新しいレコードの作成、既存のレコードのフェッチ/検索、レコードの更新、レコードの破棄などのビジネスロジックに焦点を当てています。接続するデータベースに関係なく、使い方はまったく同じです。さらに、Waterlineを使用すると、各モデルのデータが異なるデータベースに存在する場合でも、モデル間の関連付けを.populate()できます。つまり、アプリのモデルをMongoからPostgreSQL、MySQLに、そして再び最小限のコード変更で切り替えることができます。低レベルのデータベース固有の機能が必要な場合は、Waterlineは、モデルの基盤となるデータベースドライバーと直接対話できるクエリインターフェイスを提供します（.query()および.native()を参照）。
シナリオ
付随するモバイルアプリを備えたeコマースWebサイトを構築しているとします。ユーザーはカテゴリ別に製品を参照するか、キーワードで製品を検索して購入します。それだけです！アプリの一部はごく普通です。ログイン、サインアップ、注文/支払い処理、パスワードのリセットなどのAPI駆動のフローがあります。ただし、ロードマップに潜んでいる、より複雑になる可能性のある、いくつかのありふれた機能があることがわかります。案の定
柔軟性
ビジネスにどのデータベースを使用したいかを尋ねます
「データ…何？急がないで、間違った選択をしたくありません。運用/ ITに任せます。先に進んでください。」
Webアプリケーション/ APIに1つのデータベースを選択するという従来の方法論は、実際には一部の本番ユースケースでは不可能です。ほとんどのアプリは1種類のデータベースだけで済む一方で、一部のアプリケーションは既存のデータセットとの互換性を維持するか、（大量の本番アプリで作業している場合は）パフォーマンス上の理由から複数の種類のデータベースを使用する必要があります。
Sailsはデフォルトで`sails-disk`を使用するため、ローカルの一時ファイルをストレージとして使用して、設定なしでアプリの構築を開始できます。実際に切り替える準備ができたら（そして、それが何であるかを誰もが知っている場合）、アプリのデータストア設定を変更するだけです。
互換性
プロダクトオーナー/ステークホルダーがあなたに近づいてきて、こう言います
「あ、ところで、製品は実際にはすでに私たちのPOSシステムで稼働しています。ERPのようなものだと思います。「DB2」のようなものです。とにかく、きっとわかると思います。簡単ですよね？」
多くのエンタープライズアプリケーションは、既存のデータベースと統合する必要があります。運が良ければ、1回限りのデータ移行で済む場合がありますが、より一般的には、既存のデータセットは他のアプリケーションによって変更されています。アプリを構築するには、複数のレガシーシステムからのデータ、または別の場所に保存されている別のデータセットと結合する必要がある場合があります。これらのデータセットは、世界中に散らばった5つの異なるサーバーに存在する可能性があります！1つのコロケーションデータベースサーバーには、リレーショナルデータを含むSQLデータベースが格納されている場合がありますが、別のクラウドサーバーには、少数のMongoまたはRedisコレクションが格納されている場合があります。
Sails / Waterlineを使用すると、ローカルまたはインターネット上の任意の場所で、異なるモデルを異なるデータストアに接続できます。レガシーデータベースの奇妙でクレイジーな列名を持つカスタムMySQLテーブルにマップするユーザーモデルを構築できます。同様に、DB2のテーブルにマップする製品モデル、またはMongoDBコレクションにマップする注文モデルについても同様です。何よりも、これらの異なるデータストアとアダプター全体で`.populate（）`できるため、モデルを別のデータベースに配置するように設定しても、コントローラー/モデルコードを変更する必要はありません（重要な本番データを移行する必要があることに注意してください。手動で）。
パフォーマンス
夜遅くにラップトップの前に座って、あなたは気づきます
「キーワード検索をどのように行うことができますか？製品データにはキーワードがなく、ビジネスではnグラム単語シーケンスに基づいて検索結果をランク付けしたいと考えています。また、この推奨エンジンがどのように機能するかわかりません。また、今夜「ビッグデータ」という言葉をもう一度聞いたら、辞めてコーヒーショップに戻ります。」
では、「ビッグデータ」はどうでしょうか？通常、ブロガーやアナリストがその流行語を使用するとき、データマイニングとビジネスインテリジェンスを思い浮かべます。複数のソースからデータを取得し、処理/索引付け/分析し、その抽出された情報を他の場所に書き込み、元のデータを保持するか、破棄するプロセスを想像できます。
ただし、同じ種類の索引付け/分析ニーズに適した、より一般的な課題がいくつかあります。たとえば、「運転方向-近接」検索などの機能や、関連製品の推奨エンジンなどです。幸いなことに、多くのデータベースは特定のビッグデータユースケースを簡素化します。たとえば、MongoDBは地理空間インデックスを提供し、ElasticSearchは全文検索のデータのインデックス作成を hervorragend サポートしています。
データベースを意図したとおりに使用すると、特に複雑なレポートクエリ、検索（実際にはカスタマイズされたソート）、NLP /機械学習に関して、途方もないパフォーマンス上のメリットが得られます。特定のデータベースは、従来のリレーショナルビジネスクエリへの回答に非常に優れていますが、他のデータベースは、超高速の読み取り/書き込みのための最適化とトレードオフの両方で、マップ/縮小スタイルのデータ処理に適しています。この考慮事項は、アプリのユーザーベースが拡大するにつれて特に重要になります。
アダプター
ほとんどの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'
}
// ...
アナロジー
完成したペンとインクのフォームがいっぱい入ったファイルキャビネットを想像してみてください。すべてのフォームには同じフィールド（「名前」、「生年月日」、「maritalStatus」など）がありますが、各フォームで、フィールドに書き込まれた値は異なります。たとえば、あるフォームには「Lara」、「2000-03-16T21:16:15.127Z」、「single」が含まれている場合がありますが、別のフォームには「Larry」、「1974-01-16T21:16:15.127Z」、「married」が含まれている場合があります。
ホットドッグビジネスを経営していると想像してみてください。あなたが非常に組織化されているなら、あなたはあなたのファイルキャビネットを次のようにセットアップするかもしれません
- 従業員（従業員レコードが含まれています）
氏名時給電話番号
- 場所（運営する各場所のレコードが含まれています）
番地市都道府県郵便番号購入- この場所で発生したすべての購入のリスト
マネージャー- この場所を管理する従業員
- 購入（顧客の購入ごとにレコードが含まれています）
購入場所購入済み商品作成日時
- 商品（さまざまな商品提供のレコードが含まれています）
メニュー名価格カロリー数真肉の割合販売場所- この商品が販売されている場所のリスト。
Sailsアプリでは、モデルはファイルキャビネットの1つに似ています。レコードが含まれており、これはフォームに似ています。属性は、各フォームのフィールドに似ています。
注意事項
- 組み込みのORMであるWaterlineをオーバーライドしている場合、モデルに関するこのドキュメントは適用されません。その場合、モデルは、使用しているORMライブラリ（例：Mongoose）に加えて、設定した規則に従います。
sailsjs.comでのエクスペリエンスを向上させるには、ブラウザを更新してください。
概念
愛を込めて作られました
Sailsフレームワークは、貢献者の助けを借りて、テキサス州オースティンにあるウェブ＆モバイルショップによって構築されています。私たちは2012年にNode.jsプロジェクトを支援するためにSailsを作成しました。当然のことながら、私たちはそれをオープンソース化しました。それがあなたの人生を少しでも楽にすることを願っています！
© 2012-2024 The Sails Company。
SailsフレームワークはMITライセンスの下でフリーかつオープンソースです。
イラスト：Edamame。