４．エディションに依存しない開発
SQL Server 2017ではエディションを意識しない開発が可能になっています。どういうことかというと、例えば、あるシステムで当初はStandard Edition（SE）を使用していたが、データ量やアクセス数の増加によりEnterprise Edition（EE）にアップグレードする場合があったとします。
この時に、アプリケーションとしてSEで開発していると、SQL ServerのアップグレードによりSQL Serverだけでなく、アプリケーションもEE向けに書き換える必要が出てきます。例えば、パーティションを使用していて、パーティションを考慮したクエリに書き換えるなどアプリケーション側でも考慮が必要なケースが発生します。
SQL Server 2017だと、SEでもパーティションの機能を使用することができるので、SEの段階でパーティションを使用して開発しておき、データベースだけエディションをEEに変更する、ということも可能になります。これは、ISVのようなパッケージ製品を開発している会社にもメリットがあるケースがあります。例えば、パッケージ製品で使用するDBのエディションを、顧客の規模や要件に合わせて切り替えているようなケースです。
このような場合、EE用とSE用でソースを分けて管理していることがあり、ソース修正時のメンテナンス性が落ちてしまうことがあります。SQL Server 2017にすれば、共通のソースを管理すればよくなる為、エディション毎の管理から解放されます。
共通ソースの管理
もちろん、SQL Server 2008でSEを使用していて、アップグレード時にパーティションを使用する、ということもできるので、SEのデータベース上に数百GBのテーブルがあるような環境であれば、SQL Server 2017への移行時にパーティションテーブルに切り替えることで、パフォーマンスが劇的に改善する、なんてことがあるかもしれません。
SQL Server 2017のエディション毎の機能差については、こちらをご参照頂ければと思います。
パーティション以外にも、先ほどご紹介した列ストアインデックスや、セキュリティの機能なども使用可能なので、SEを使用している環境であれば、バージョンアップするだけでEEにアップグレードしたようなメリットが得られる可能性があります。
***
以上、SQL Server 2008からアップグレードすることで使えそうな機能について解説してきました。SQL Server 2017にすることでSQL Server 2008にはなかった便利な機能が使えそう、ということはご理解いただけたかと思います。では、実際にアップグレードしようした時に、何か問題が発生したりすることはないのでしょうか。
次回は実際のアップグレード時に気にすべきところについてお話したいと思います。
