Bir PostGIS tablosunda geometri türlerini karıştırma

Aşağıdaki sorunla karşılaştım. Oracle veritabanından PostgreSQL + PostGIS'e geçmem gerekiyor. Şu anda tüm türlerin tüm geometrileri bir tabloda depolanmaktadır ve her kayıt aynı katmanın özelliklerini gösteren bir "kapak" alanı içermektedir.

Böyle bir yöntemi kullanmanın artıları ve eksileri nelerdir? Veritabanını üçüncü taraf yazılımıyla kullanmam gerekmiyorsa, verileri birden fazla tabloya bölmeli miyim? Mekansal sorguların performansı ne durumda, indeksler bana yardımcı olacak mı?

Üçüncü taraf desteğine ihtiyacınız yoksa ve bunları aynı tabloda tutarak yazarak sorgulama gereksinimi duymuyorsanız gayet iyi çalışır. Alternatif olarak, Eylem PostGIS'in 3. bölümünde tartışıldığı gibi bir kalıtım modeli kullanabilirsiniz.

http://www.postgis.us/chapter_03_edition_1

Bir mimari açıdan bakıldığında, PostGIS bir sorguda birden fazla farklı türün kullanılıp kullanılmayacağını umursamıyor. Oracle'da sizin için iyi bir performans sergilediyse, PostGIS'te daha iyi bir performans göstermemiş gibi olacak.

Bunu bölmek için 2 neden var (ya da gerektiğinde daha sonra yapılabilir): 1) İnsanların geometri koleksiyonları, dairesel dizgeler ve istemediğiniz farklı türler eklemesini önleyin (hangisini bir kısıtlamayı el ile tanımlayabilirsiniz?) )

2) Eğer bir milyar puanınız ve 1000 poligonunuz varsa ve poligon testlerinde çok fazla puan alıyorsanız, sorgulamak ve birleştirmek - bir milyara karşı - 1000'e kadar kayıt tablosuna katılırsanız, hız çok daha iyidir. milyardan milyara kadar bir kayıt tablosu. Bu (PostGIS'e özgü değil) düşündüğüm herhangi bir uzaysal veritabanı için geçerli olacaktır. Bu, tahmin edeceğim tüm ilişkisel sorgular için de geçerlidir (mekansal sorgulara özgü değildir).

Bu beni gerçekten rahatsız ediyor. Sanırım hepsi tek bir katmanda veri içeren çok sayıda CAD dosyası gördüm, sadece renkle farklılaştırdım.

Asıl konu, verilerin yapıya veya niteliklere göre düzenlenmesi arasında bir seçimdir .

Bu seçim göz önüne alındığında, verilerimi her zaman veri yapısıyla organize etmeye giderdim.

Bir başlangıç ​​için, veri işlerken atlamak için daha az çembere sahip olacaksınız (örneğin , id = X VE lid = Y olan tablodan a, b, c yi seçmek yerine, id = X tablosundan a, b, c seçin )

Ardından, veritabanlarının neden birden fazla tabloya izin verdiğini göz önünde bulundurun - bir veri biçimi belirli veri yapıları sağlıyorsa, verileri kullanırsanız daha verimli bir şekilde işleyeceğini düşünmeniz gerekir.

Ancak asıl mesele (benim için), verileri başka bir sisteme taşımak istediğinizde. O zaman bunun gerçek bir zorluk olduğunu düşünüyorum, çünkü son uygulama verileri aynı şekilde kullanmayabilir. Bu senaryoda birçok insanın sıkıştığını gördüm.

Böylece - benim tecrübeme göre - iyi (daha derin ve daha yapılandırılmış) bir veri modeline sahip olduğunda, verileri iki kat daha verimli kullanabilecek ve aktarabileceksiniz.