ピースペース

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

leave a comment »

既存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というのが追加になっていた。
こちらは副次キーも作成されるらしい。当初の目的にはこっちの方が良かったのかもしれない。

Written by nasu38yen

2015年7月30日 @ 8:28 AM

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。