NoSQLにデータを格納してみた

既存Webサイトの再構築案件があって、
データの登録先をSQLからAzure Storage Tableに移動してみた。
ユーザーによって項目の要求が微妙に違うようなデータの格納先にぴったりだと思った。
スキーマーがないのでその微妙に異なる要求をそのまま格納できる。

問題は、コード上でそのデータのModelをどうするか？
せっかくのスキーマレスをここで型にはめるわけにはいかない。
型を定義せずに扱うには、DynamicTabaleEntity.Propertiesに準じて、
IDictinary<string, object>に格納すると良い。
コントローラは項目の違いを気にしないで同じデータとして扱うことができて、
Viewに投入するときは、ExpandoObjectを使ってdynamicなオブジェクトに変換できる。

private dynamic GetDynamicObject(IDictionary<string, string> dictionary)
{
    IDictionary<string, object> expando = new ExpandoObject();
    foreach (var item in dictionary)
        expando.Add(item.Key, item.Value);
    return (ExpandoObject)expando;
}

SQLなDBであっても同じデータをjsonに変換してひとつの項目に格納しておくことはできる。
つまり、コントローラやViewをまったく変更せずに、違いをRepositoryに押し込むことはできる。
わけだが、DBエクスプローラのようなツールを使った手軽なデータ編集などの作業を考えると、
jsonに変換されたデータはやはり扱いづらい場合があるような気がする。

スキーマレスなTableには、商品区分と商品を同じTableに格納することができるわけで、
同じTableという名前がついていてもこれはもうまったく別物だ。
副次キーは定義できない、リレーションもない。
SQL脳そのままでNoSQLをデザインすることはできない。
なので、既存のSQLデータをそっくりそのままNoSQLに移動するのはムリ！
と割りきるのが得策な気がする。
SQL or NoSQL ではなくて SQL and NoSQL
その部分のデータは無理せずNoSQLにぶち込んじゃいましょう！的な
で、柔軟でかつスッキリできる。

ところで、久しぶりにAzureにアクセスしたらDocumentDBというのが追加になっていた。
こちらは副次キーも作成されるらしい。当初の目的にはこっちの方が良かったのかもしれない。