kazuk は null に触れてしまった

C# / .NET 系技術ネタ縛りでお送りしております

KVSでは join がアレとか言う奴は一回RESTへ帰れ


煽りはタイトルだけ。
 
RowKey の設計レベルの話なんだが、 Table に受注(Order) と受注明細(OrderLine) を格納するとする。
 
Order と OrderLine は親子関係なんで、DBに格納するって場合には Order テーブルと OrderLine テーブルに格納する事になり、これを 1対多結合のリレーションとして捕らえて join する事になる。
 
これを単純に、そのまんまAzureTableに持っていくと Order の RowKey には受注IDが入り、OrderLineは受注IDで引ける必要があるから同様に受注ID+明細IDを入れる事になる。
 
RowKey の編成の仕方は順序でとりやすいように前0埋めの固定長で 受注Id をn桁 明細Idを m桁とする。
 
Table Order
00001 受注レコード
Table OrderLine
000010001 明細レコード
000010002 明細レコード

000010003 明細レコード
 
ってな寸法。(例はn=5, m=4)
 
これを
from order in tableClient.CreateQuery<Order>
where order.RowKey==orderId
select order;
 
from orderLine in tableClient.CreateQuery<OrderLine>
where order.RowKey>orderId && order.RowKey<=orderId+"9999"
select orderLine
 
と引く (string には >= がねーとか言われて通らないのはご愛嬌、string.Compare( a,b,StringComparizon.Ordinal )>0 とか書かないと行けないのはしってる)
 
でも、これ1テーブルに置いちゃってしまえば REST では $filter=(RowKey ge ‘00001’) and (RowKey lt ‘000019999’ ) で1発引きが可能。
 
Azure にはトランザクション課金もないわけじゃないんで、お金的にもこっちの方が良いのは明白。
 
ただし、MS謹製のTableClientは一発のリクエストでは1個のエンティティ型しか扱えないんですよねー、残念でしたって所が罠で、前のエントリーで言ったようにRESTに自分が行った理由でもあったりして。
 
TableClientは捨ててRESTで考えたほうが良いです、RDMBSのテーブルとKVSのテーブルは別物、どっちかというとRDBMSのDBファイル程度の感覚でKVSのテーブルを見たほうが良い。
 
KVSでjoin がアレなんて大嘘だよーって事、だまされちゃいけません。
RowKey をどう編成するかしだいで親子リレーションの一発引きなんてRESTで見てる人には余裕ちゃんでございます。
 
広告

コメントを残す

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

WordPress.com ロゴ

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

Twitter 画像

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

Facebook の写真

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

Google+ フォト

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

%s と連携中

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