新しい職に就いてから夏を楽しむまで、しばらくブログを書いていませんでした。Iterable Cursor シリーズを完結させる予定ではありますが、ファイルジオデータベースの制限とその後のバグに直面し、共有する価値があると思いました。まずは制限についてです....<\/EM><\/P><\/P>2006年にファイルジオデータベース（FGDB）が導入された際、それはパーソナルジオデータベース（PGDB）に対する強化された高性能な代替手段として宣伝されました。大規模なデータセットや多数のデータセットのコレクションはパーソナルジオデータベースにとって課題であることは確かです。例えば、Microsoft Access データファイル（*.mdb;*.accdb）はサイズが2GBに制限されており、2006年当時はそれほど多くありませんでしたが、今日ではほとんど無いに等しい容量です。ファイルサイズの制限に加え、パーソナルジオデータベースのパフォーマンスは総データ量が約500MBになると低下し始めます（詳細はTypes of geodatabases<\/A>を参照）。もう一つの要因として考えられるのは、Esriが言及していませんが、2000年代半ばのJetデータベースエンジンの廃止です。<\/P><\/P>思い出をたどるか、Esri Blogs を見ると、File Geodatabase を使うべき5つの理由<\/A>があります：<\/P>サイズ<\/STRONG><\/P>データベースサイズは利用可能なディスク容量によってのみ制限されます。デフォルトでは、個々のテーブルやフィーチャクラスは最大1TBまで可能です。設定キーワードを使用すると256TBまで拡張できます。<\/P><\/P>多用途性<\/STRONG><\/P>WindowsやUNIX（SolarisやLinux）など、多くの異なるオペレーティングシステムで動作します。<\/P><\/P>速度<\/STRONG><\/P>優れたパフォーマンスとスケーラビリティを提供します。例えば、3億以上のフィーチャを含む個別のデータセットや、1ファイルあたり500GBを超えるスケール可能なデータセットを非常に高速なパフォーマンスでサポートします....<\/P><\/P>編集モデル<\/STRONG><\/P>File Geodatabase は shapefile に似た編集モデルを使用し、一人の編集者と複数の読み取り者をサポートします。各スタンドアロンフィーチャクラス、テーブル、およびフィーチャデータセットは異なる編集者によって同時に編集できますが、一度に編集できる編集者は一人だけです....<\/P><\/P>圧縮<\/STRONG><\/P>File Geodatabases はまた、ユーザーがフィーチャクラスやテーブルを読み取り専用形式に圧縮してストレージ要件をさらに削減できるようにします。これにより、パフォーマンスを低下させることなくジオデータベース全体のディスク上のフットプリントが削減されます。<\/P><\/BLOCKQUOTE><\/P>ブログ記事で説かれている5つの理由には異論はありません。それぞれ正確であり、その当時Esriが新しいファイルシステムベースのジオデータベース形式を作成する理由として妥当だと思います。しかしブログの8年前のコメントにもあるように、ファイルジオデータベースは当時完璧ではなく、今日でも欠点があります。<\/P><\/P>一部の人にとってファイルジオデータベース最大の欠点は所有権です。これはAccess/Jetもプロプライエタリであるためパーソナルジオデータベースから大きく変わったわけではありませんが、機会損失を意味します。数年後EsriはついにファイルジオデータベースAPI (<\/EM>File Geodatabase API details<\/EM><\/SPAN><\/A>) をリリースしましたが、仕様書は公開されていません。API公開は仕様書公開よりもかなり閉鎖的です。また、FGDB API はファイルジオデータベース内の機能の一部しか実装していません。<\/EM>
<\/P>
思い出をたどるか、Esri Blogs を見ると、
サイズ<\/STRONG><\/P>データベースサイズは利用可能なディスク容量によってのみ制限されます。デフォルトでは、個々のテーブルやフィーチャクラスは最大1TBまで可能です。設定キーワードを使用すると256TBまで拡張できます。<\/P><\/P>多用途性<\/STRONG><\/P>WindowsやUNIX（SolarisやLinux）など、多くの異なるオペレーティングシステムで動作します。<\/P><\/P>速度<\/STRONG><\/P>優れたパフォーマンスとスケーラビリティを提供します。例えば、3億以上のフィーチャを含む個別のデータセットや、1ファイルあたり500GBを超えるスケール可能なデータセットを非常に高速なパフォーマンスでサポートします....<\/P><\/P>編集モデル<\/STRONG><\/P>File Geodatabase は shapefile に似た編集モデルを使用し、一人の編集者と複数の読み取り者をサポートします。各スタンドアロンフィーチャクラス、テーブル、およびフィーチャデータセットは異なる編集者によって同時に編集できますが、一度に編集できる編集者は一人だけです....<\/P><\/P>圧縮<\/STRONG><\/P>File Geodatabases はまた、ユーザーがフィーチャクラスやテーブルを読み取り専用形式に圧縮してストレージ要件をさらに削減できるようにします。これにより、パフォーマンスを低下させることなくジオデータベース全体のディスク上のフットプリントが削減されます。<\/P><\/BLOCKQUOTE><\/P>ブログ記事で説かれている5つの理由には異論はありません。それぞれ正確であり、その当時Esriが新しいファイルシステムベースのジオデータベース形式を作成する理由として妥当だと思います。しかしブログの8年前のコメントにもあるように、ファイルジオデータベースは当時完璧ではなく、今日でも欠点があります。<\/P><\/P>一部の人にとってファイルジオデータベース最大の欠点は所有権です。これはAccess/Jetもプロプライエタリであるためパーソナルジオデータベースから大きく変わったわけではありませんが、機会損失を意味します。数年後EsriはついにファイルジオデータベースAPI (<\/EM>
Esri はファイルジオデータベースで速度やサイズなどを改善するために努力していましたが、その過程で妥協もしていました。同じAccess/Jetバックエンドはパーソナルジオデータベースで大規模なデータセットに課題をもたらす一方で、ArcGIS ソフトウェア内外で作業する際には豊富なSQLサポートも提供しています。Access/Jetから離れて新しいファイルシステムベースのジオデータベース形式を作成する決定は、Esriが独自にSQLサポートを構築しなければならないことを意味しました。不幸にもリリース直後から不足しており、その後10年間ほとんど変わっていません。<\/P>
ファイルジオデータベース内のSQLサポートについて学ぶにはいくつか異なる場所があります：<\/P>
<\/_p?>
上記の様々なドキュメントやリンクを見ると内容がかなり重複しています。ただし重要な記述が一部だけ存在する場所もあり、それらを知っていることはエラー解決やファイルジオデータベース内のデータから得られる不自然な結果を理解する際に重要です。<\/_p?>
私はファイルジオデータベースのすべての制限（SQLサポートも含む）に光を当てるつもりはありません。まず第一に、それにはかなりの労力とスペースが必要だからです。パーソナルジオデータベースにも制限があるように、ファイルジオデータベースにも制限があります。そしてSQLサポートは後者における大きな制限です。パワーユーザーや開発者にとって、この制限を理解することは重要です。なぜなら個人用またはエンタープライズジオデータベースとファイルジオデータベース間で切り替える際に経験や結果が異なる可能性があるからです。<\/_p?><\/_body?><\/_html>
Joshua, are there workflows you have migrated to GeoPackage to take advantage of its SQL support in any 3rd party software or Data Interoperability/FME?
サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
