続・SharePoint のリストでカスケード分類っぽいことを実現してみる

前回「SharePoint のリストでカスケード分類っぽいことを実現してみる」の続きです。

関数を使って、カスケード分類ちっくな挙動を作ってみた訳ですが、実データに適応してみたところ、やはりというか、仕様に穴がありました。

前回の関数は、分類が「xxxx-xxxx-xxxx」形式であること、つまり必ず分離記号「-」が 2つ存在することが前提だったんですよね。しかし、分類が必ずしも三階層あるとは限りません。こういうケースは想定しておかないといけないですね。

そこで、IF 関数 と ISERROR 関数を加えて、集計値を書き直しました。

計算1：=IF(ISERROR(SEARCH(“-”,分類,1)),””,SEARCH(“-”,分類,1))
計算2：=IF(ISERROR(SEARCH(“-”,分類,計算1+1)),””,SEARCH(“-”,分類,計算1+1))
計算3：=IF(計算2=””,分類,LEFT(分類,計算2-1))
大分類：=IF(ISERROR(LEFT(分類,計算1-1)),分類,LEFT(分類,計算1-1))
計算4：=IF(ISERROR(LEN(計算3)-計算1),””,LEN(計算3)-計算1)
中分類：=IF(計算4=””,””,RIGHT(計算3,計算4))
計算5：=IF(計算2=””,””,LEN(分類)-計算2)
小分類：=IF(計算5=””,””,RIGHT(分類,計算5))

今回も、基準になる列名は「分類」、区切り値が「-」です。

で、次にこの関数式をシンプルにまとめようとしたのですが…。無理でした。SharePoint の IF 関数は、最大ネスト7回、という制限があり、それを超えてしまうんですね。
抜本的にロジックを見直せば可能かもしれませんが。

計算n 列は、コンテンツタイプの管理を有効にして、非表示にすると良いと思います。

後、心配だったレスポンスについても調査しました。この関数を1万アイテム登録されたリストに組み込んでみましたが、特にレスポンスの劣化はみられませんでした。関数による集計値は、表示時に計算されるのではなく、保存時に DB に登録されるようです。あくまで現象からの推測なので、確かなことは判りませんが…。ただ、1万件を登録した後から集計値列を作成すると、[OK] をクリックしてから実際に列が作成されるまで、非常に時間を要したことからも、アイテム作成/更新時に DB に保存されていると考えられます。

SharePoint Cascaded Lookup

SharePoint のリストでカスケード分類っぽいことを実現してみる
Windows SharePoint Services 3.0 のヘルプと使い方＞数式と関数
SharePoint2007 で利用できる関数とそのお作法
Infopath2003 を利用して、階層型（カスケード）分類選択を実現する
SharePointでダイナミックな分類選択を可能にする Query Based Lookup Field