ArcGISドキュメントではこのテーマ領域を「distributed data」と呼び、データ移動に使用できるさまざまな戦略について一般的なガイダンスを提供しています： http://desktop.arcgis.com/en/arcmap/latest/manage-data/geodatabases/understanding-distributed-data.htm。
ObjectClassがまだバージョン管理登録されていない場合でも、それをGeodatabase Replication利用目的で登録することが適切かどうかは場合によります。 これはデータ更新方法に関連します。 バージョン管理登録されたほとんどすべてのデータは「transactionally」に更新されます。つまり、一度に変更される総レコード数はごくわずかです。この種の更新はバージョニングおよびGeodatabase Replication双方と互換性があります。他方、「truncate and add」、「delete and replace」、または「copy and paste」のような方法で更新されるデータもあります。この場合、大部分のレコードが物理的に更新されます（たとえ大多数の値が同じでも物理的なレコード自体は置き換えられています）。この種の更新はGeodatabase Replicationにはあまり適していません。egdbhealthにはObjectClasses のバージョニングおよびレプリケーション状況について教えてくれます。しかし、それらObjectClasses が実際どんな方法で更新されているかは知りません。望むところではバージョン管理登録されたものはtransactionally 更新されており、それゆえGeodatabase Replication に適した候補です。
ObjectClass にアーカイブ機能が有効になっている場合、更なる考慮事項があります。たとえば計画中のデータ交換によって更新頻度が増加するとアーカイブ情報量も望ましくない形で増加する可能性があります。
バージョン管理されたアーカイブ有効ObjectClassesの場合、アーカイブ情報は別個「history」テーブルに格納されます。このテーブルサイズはバージョン管理されたデータクエリ性能には影響しません。この場合主な設計上考慮点はアーカイブ情報全体を保持し利用することが実際的かどうかです。多くの場合それは可能でしょう。しかし判断にはObjectClass のアーカイブ状況および計画中更新頻度について知る必要があります。
非バージョン管理アーカイブ有効ObjectClasses（およびブランチバージョン管理ObjectClasses）の場合アーカイブ情報は主テーブル内にあります。そのためアーカイブ情報急増によってObjectClasses および／またはeGDB のパフォーマンス調整ニーズが変化します。Egdbhealth は将来更新ニーズについて知りません。しかし非バージョン管理アーカイブ有効ObjectClasses の過去更新パターンについて報告できます。Context Excel ファイルにはNvArchEditDatesSql シートがありeGDB 内非バージョン管理アーカイブ有効各ObjectClass 用SQL文があります。この文は自動実行されません。それらは資源集約型クエリーであり全状況で関連情報提供しないためです。
\/><\/P>
<\/P>
しかし、このシステム設計のケースでは、レコードが時間とともに蓄積された速度を確立することは、データ交換戦略の計画に非常に関連性があるかもしれません。SQL Server Management Studio のような SQL クライアントを使用して、対象の ObjectClasses に対するクエリを実行し、データ更新の速度感を把握してください。この例では、典型的な更新は小規模（1レコード）ですが、少なくとも1回は ObjectClass のサイズに対して大きな更新（2018年4月8日に289レコード）があったというパターンが見られます：<\/P>
サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
