NoSqlはSQLデータベースに代わるものではありませんが、標準SQLがデータを保存するための最良のアプローチではない多くの状況で有効な代替手段です。
「データウェアハウス」にデータを保存し、そのデータをクエリして抽出する必要がある場合は、SQLが最適なソリューションであると教えられたため、使用するSQLエンジンを決定するだけで、ゲームは終了します。
2012年には、この提案は間違っていました。つまり、SQLがデータを格納する「唯一の方法」であるとはもはや考えられませんが、他の選択肢があり、それらはNOSQLと呼ばれることを知っておく必要があります。この用語では、SQLに基づかないさまざまなストレージメカニズムがあり、.NETにはRavenDBと呼ばれる優れた製品があります（RavenDbの非常に優れた紹介はMauroブログにあります）。
標準SQLとの最初の大きな違いは、スキーマがないことです
SQL Serverの最も厄介な制限の1つは、ストレージに保存するデータの正確な形式を指定する必要があることです。 これは多くの正当な理由で必要ですが、特にソフトウェアが主にOOPの概念に基づいている場合は、実際には気にしない状況があります。このオブジェクトがあるとします
1: class player
2: {
3: public String Name { get; set; }
4:
5: public DateTime RegistrationDate { get; set; }
6:
7: public Int32 Age { get; set; }
8: }
しばらくの間、このオブジェクトのカプセル化が不十分であるという懸念はありませんが（取得してインストールするためのパブリックメソッドがあります）、このオブジェクトをどこかに「保存」する必要性にのみ焦点を当てています。 標準のSQLリポジトリを使用する場合、最初に行う必要があるのは、テーブルを作成し、次に列を定義し、[名前]列の最大長を定義し、最後に専用のデータレイヤーを使用または作成するORMを選択することです。最後に、オブジェクトを保存できます。
カラスを使用している場合、必要なコードはこれだけです
1: var store = new DocumentStore { Url = "http://localhost:8080" };
2: store.Initialize();
3: using (var session = store.OpenSession())
4: {
5: var player = new Player
6: {
7: Age = 30,
8: RegistrationDate = DateTime.Now,
9: Name = "Alkampfer",
10: };
11: session.Store(player);
12: session.SaveChanges();
13: }
サーバーは単にオブジェクトを取得して保存します。
オブジェクトをデータウェアハウスに保存するには、保存するオブジェクトをリポジトリに通知する「保存」と、実際に保存を実行する「SaveChanges」の2つの関数のみが必要です。
この単純なコードフラグメントで何が得られますか？サーバーアドレスの標準ブラウザに移動するだけで、データベースの内容が表示されます。
単純なオブジェクト挿入後のデータベースの内容
図では、データベースcrowの内容を確認できます。このデータベースにはプレーヤーが含まれており、オブジェクトの横にある小さな1はIdです。これは、Ravenが内部でこのオブジェクトを一意に識別するために使用します。 Sys Doc Hilo / Playersと呼ばれる別のオブジェクトは、Hiloアルゴリズムを使用してPlayersオブジェクトの識別子を生成します。
これですべてです。スキームを定義する必要はありません。オブジェクトをリポジトリと互換性を持たせるために特別なIdプロパティやその他の要件を設定する必要はなく、.NETオブジェクトとオブジェクトのStoreメソッドを呼び出すだけです。データベースにあります、Period！