EntityFrameworkのモデルファースト利用について
既存システムに対して新たなサービスを構築する際にはモデルファーストでEntityFrameworkを利用することになる。
面倒なＳＱＬ文字列組立やマッピングの為のコードから解放されるが既存のモデルから単純に取り込むといろいろ弊害が起きる。
・エンティティがモデル上に反映されない
レコード識別のためのキーを自動的に判別するが、
複合キー
View
などEntityFramework的に認識できず、無視される場合がある。
・認識されたとしても、いざ更新しようとしても例外が発生して更新できない
PKが認識できない場合、読み取り専用扱いとなり更新処理で例外発生となる。
VisualStudio上のソリューションエクスプローラーでedmxファイルを右クリックしXMLエディターで見てみると
<!--生成中に見つかったエラー:
警告 6002: テーブル/ビュー 'XXXXXX' には主キーが定義されていません。主キーは推論され、定義は読み取り専用のテーブル/ビューとして作成されました。-->
などと書かれている。。。
プライマリキーを設定し忘れたみたいです。。
ちなみに今時のWebフレームワークはサロゲートキーが前提になってるみたいですね。
複合主キーとかあまり気にせず実務で使ってましたが、これからは何も考えず「ID」って主キーをつけることにします。
ナチュラルキーにユニーク制約つけとけばいいかな？
って思ったけど、ER図をリバース生成して設計書完成！ってやりたいときにIDだらけでわけわからん感じになりそう。。
SQLServerをデータソースとしたレポーティング機能について
SQLServerを業務利用している場合、ユーザ要望に応じた定型レポートを
簡単に実現したいと思って調査。
ReportingServiceとは
SQLServerについてくるおまけの一つ。
（製品のEditionによるかもしれませんが）
SQLServerReportingService(SSRS)：定型レポート作成
ノンプログラミングでデータベースなどからWebベースの定型レポートが作成できる。
SQLServerAnalysisService(SSAS)：非定型データ分析
Excelをフロントエンドにしてデータ分析が行える。
みたいな棲み分けでしょうか？
SSRSはSQLServerに格納されたデータから定型レポートを作成するためのサービスです。
SQLServer2008からは専用サービスがHTTPリスナーを兼ねているのでIISなどのサービスがない
状態でもブラウザ経由でレポート参照が可能です。
利点としては
- 定型レポートとしてグラフとかつけたリッチなアウトプットが作れる。
- 外部出力もExcelやPDFなど標準で利用できる。
実務上利用する際の懸念事項としては
・SQLServerの１機能として位置づけられており、基本的にはDBサーバー自体をReportingサービス用に公開しなければ使えない。
実務利用上はDBサーバーを直接公開することはあまりしないし、
SharePointServerとかReportingService専用にSQLServerをインストールしたサーバーを準備すればよいみたいだが、お試しで使うにはハードルが上がる。
※ちなみにSQLServerExpressEditionでもオプションでReportingサービスが使えるけど、外部サーバーのデータをソースにできない制限があるみたいだ。
単純に実務利用中のDBに対してReportingService以外の特別なサーバーを立てずにやろうとすると
- DBサーバーでReportingServiceで生成したレポートを定期的にメールやファイルサーバーへ吐き出す機能を利用する。
- ReportingService専用の公開サーバーを立て、ExpressEdition＋ReportingService入れて集計元データから出力データを定期的に取得し利用する。
みたいな利用方法になるが、ここまでくるとASP.NETとかで作ったほうが手っ取り早いかなってなってくるみたいな。。。
＜結論＞
SharePointとか使ってるなら使えそうだけど、そうじゃなければ自前で作ったほうが早そう。
