Kişisel coğrafi veritabanları, dizin oluşturulmuş öznitelikleri hızlı bir şekilde sorgulamak için dosya coğrafi veritabanlarından daha uygun mudur?

Bir adresi aramak için verileri sorgulayan bir ArcGIS Engine uygulaması için veri hazırlıyorum. Bazen sadece sokak adı alanında, sadece bina numarası alanında veya her ikisinde arama yaparız. Kişisel coğrafi veri tabanları veya SDE coğrafi veri tabanları kullanılırken, tek sütunlu dizinlere ek olarak çok sütunlu bir özellik dizini de eklenebilir. Bazı nedenlerden dolayı, ESRI öznitelik dizinleri oluşturma makalesine göre, dosya coğrafi veritabanlarını kullanırken çok sütunlu öznitelik dizinleri mümkün değildir. Neden böyle olduğunu söylemiyorlar - belki dosya coğrafi veritabanları nedense onlara ihtiyaç duymuyor?

Bina numarası alanındaki ve sokak adı alanındaki çok sütunlu bir dizin, her iki alanı aynı anda ararken sorgu performansımı teorik olarak iyileştirmelidir, ancak kişisel bir coğrafi veritabanını kullanmaya değer mi? Kişisel bir coğrafi veritabanı kullanmanın olumsuz yönlerinin çok sütunlu dizinin faydalarını olumsuz etkileyebileceğini hissediyorum.

Esri'nin kişisel coğrafi veri tabanlarından uzaklaşmamızı istediği izlenimi altındaydım, ancak bu kişisel coğrafi veri tabanlarının daha iyi bir seçenek olduğu bir durum mu? Bununla ilgili herhangi bir deneyiminiz varsa, bilmek isterim.

Sorunuzun ilk bölümünü yanıtlamak için, Çok Sütunlu Dizinler Hakkında Öznitelik Dizinleri Oluşturma yardım dosyasındaki ek metne bakmanın yardımcı olacağını düşünüyorum.

Alanların çok sütunlu bir dizinde görünme sırası önemlidir. B sütunundan A sütununun bulunduğu çok sütunlu bir dizinde, ilk aramayı yürütmek için A sütunu kullanılacaktır. Ayrıca, böyle bir indeks sadece A sütununu içeren sorgular için sadece B sütununu içeren sorgular için çok daha yararlı olacaktır.
A ve B'de çok sütunlu bir dizin oluşturun. Bu dizin, her iki sütunu da içeren sorgular için genellikle daha verimli olur. Yalnızca A'yı içeren sorgular için, bu dizin yalnızca A'daki bir dizinden daha yavaş olacaktır. Bu dizin yalnızca B'yi içeren sorgular için çok az işe yarar. Telafi etmek için B üzerinde ek bir dizin oluşturabilirsiniz.

Bu pasajların her ikisi de çok sütunlu indekslerin özel kullanım için daha iyi olduğunu göstermektedir. Ayrıca, dahil edilen sütunlardan yalnızca birini sıralamak için böyle bir dizin kullanmak aslında performansa zarar verebilir. Bu nedenle, çok sütunlu bir dizinde yer alan özelliklerin her biri için ayrı sütun dizinlerinin gerekli olması muhtemeldir.

ESRI tarafından Kişisel GDB üzerinden bir Dosya seçmenin 9 nedenini belirten eski ama ilginç bir belgeye bağlantı buldum . Performansı özel bir neden olarak belirtmesi ilginçtir. Bu performans kazancının bir kısmı dosya tabanlı depolama sisteminden kaynaklanmaktadır. Bunun çok sütunlu destek eksikliğine de yol açabileceğini düşünüyorum. Tek bir dosya olan Kişisel GDB'den farklı olarak, Dosya GDB'sindeki bir dizin GDB yapısında ayrı bir dosya olarak saklanır. Bu, belirli bir özellik sınıfı için dizin dosyasının ve öznitelik dosyasının birbirine bağlanması ve bunlara erişilmesi gerektiği anlamına gelir. Çok sütunlu bir dizinin, dizin ve öznitelik dosyaları arasında ileri geri atlamaya neden olabileceğini ve potansiyel olarak dizin oluşturma performans kazancından ağır basan bir performans vuruşuna neden olabileceğini görebiliyordum.

Kişisel GDB üzerinden GDB Dosyası ile önemli performans artışları olduğundan, muhtemelen çok sütunlu dizini uygulamaya değmez.

Her iki GDB türü ile çalışma deneyimimde, Kişisel GDB'nin dosyadan yaklaşık% 50 daha büyük çalıştığını gördüm. GDB Dosyanızla ilgili verdiğiniz verilere dayanarak, bir PGDB'ye dönüştürürseniz büyük olasılıkla ~ 300MB'lık Kişisel GDB elde edersiniz. Gördüğüm kadarıyla, hem ESRI ürünlerinde hem de ayrı ayrı MS Access veritabanlarıyla çalışmak, ".mdb" dosyaları 100 MB'ın üzerinde önemli ölçüde arttığında performans düşüşünü görmeye başlamanızdır.

Diğer bir sorun, öznitelik aramalarınızı hızlandırabilseniz bile, veri çerçevesinde hareket etme ve görünümü yenileme ile ilgili büyük bir performans isabeti görmenizdir. Katman bir PGDB içinde olsaydı hızlı çizmezdi. Coğrafi Veri Tabanı Türlerini karşılaştıran bu makale , performans farklılıkları hakkında daha fazla bilgi vermektedir.

Birçok şeyde olduğu gibi, en iyi seçim nihayetinde kullanım durumunuza göre kaybolacaktır. Access arabiriminde yapabileceğiniz sorgu ve güncelleştirme gibi veritabanına özgü çok sayıda işlem varsa, Kişisel GDB daha iyi olabilir. Yalnızca bazı sorgulamalar yapmayı planlıyorsanız, ancak öncelikle uzamsal verileri görselleştirecekseniz, performans kesinlikle GDB Dosyasının yanına düşer.

Kişisel Coğrafi Veritabanı üzerinden Dosya Coğrafi Veritabanı kullanmanın en az 9 nedeni vardır. Ne yazık ki, eski PGDB'yi tutmak için hala çok daha fazla neden var; ikileminiz bunlardan biri. (bu konuda ESRI yayını yok)

PGDB üzerinden FGDB'nin temel amacının, çok sütunlu "öznitelik" dizinleri ve diğer gelişmiş SQL işlevleri gibi işlevler yerine, depolama kapasitesi ve uzamsal verilerin performansı (çizim hızı, geri alma, uzamsal indeksleme, uzamsal sorgulama vb.) Olduğuna inanıyorum. normalde herhangi bir DBMS'nin ayrılmaz bir parçasıdır. (Hangi MS Access tabanlı PGDB ve ESRI yerel FGDB değildir) Yan not olarak; MS Access veritabanının maksimum dosya boyutu sınırı 2 GB'dir ve bu da herhangi bir PGDB'nin maksimum boyutudur. Buna karşılık, FGDB dosya boyutu sınırı 1 TB ile 256 TB'a kadar genişletilebilir.

ESRI ayrıca şunu da belirtir: SQL ifadesi oluşturmak için kullandığınız sözdizimi veri kaynağına bağlı olarak değişir. Bunun nedeni, SQL'in bir standart olmasına rağmen, tüm veritabanı yazılımlarının aynı SQL lehçesini uygulamadığıdır. ve Dosya coğrafi verileri, kapsama alanları, şekil dosyaları, INFO tabloları, dBASE tabloları, CAD ve VPF verileri de dahil olmak üzere dosya tabanlı verileri sorgulamak için, ArcGIS içinde uygulanan ve ArcSDE coğrafi veri tabanları.

Diğer bir deyişle (ve PGDB ve ArcSDE GDB bunun bir kanıtıdır) DBMS'nin altında yatan coğrafi veri tabanı bu işlevi destekliyorsa kullanılabilir olmalıdır . Bu nedenle, temelde MS Access veritabanına sahip bir PGDB'de çok sütunlu bir dizin oluşturabilirsiniz. Bu işlevselliği destekleyen temel DBMS'ye sahip tüm ArcSDE coğrafi veritabanlarıyla aynıdır.

Dosya Geodabase gelince ; En 9.2 FGDB salınımı ESRI ima Bu özelliklerin ve işlevlerin bazıları, alıntı gelecek FGDB sürümlerde eklenecektir olabileceğini; "Dosya coğrafi veri tabanları, kişisel coğrafi veri tabanları için kullanılabilen tüm özellikleri ve işlevleri desteklemez. ArcGIS 9.2'de dosya coğrafi veri tabanları tarafından desteklenmeyen en yaygın kullanılan işlevler arasında DISTINCT, GROUP BY ve ORDER BY ile AVG, COUNT, MIN, MAX ve SUM alt sorguların dışında desteklenmez. Bunlardan bazıları için destek gelecekteki sürümlerde eklenecektir. "

Dört yıl sonra sürüm 10'da bu işlevlerin ve özelliklerin hiçbiri kullanılamaz. ( Mevcut işlevlerin listesi )

FGDB'nin devam eden bir çalışma olduğu ve gerekli tüm SQL DBMS işlevlerine ihtiyaç duyduğu kadar çok sütunlu indeksleme yeteneklerine ihtiyacı olduğu görülmektedir. Sanırım ESRI geliştiricileri işlevselliğini FGDB'ye genişletmenin önemli olduğuna karar verene kadar PGDB ile sıkışıp kalacağız.

Bu konuyu / sorunu canlandırarak, mümkün olduğunda FGDB ve PGDB'yi birleştirmenin yararlı olabileceğini buldum. Örneğin, sıfırdan bir coğrafi veritabanını bir PGDB yapmak sorguların performansına büyük ölçüde yardımcı oldu. PGDB'nin boyutu, yukarıda belirtildiği gibi çok artmamalıdır.