PostGIS Veritabanı için adlandırma kuralları? [kapalı]


11

PostGIS ile bir veritabanı oluşturmaya başlıyoruz. Veritabanının, coğrafi veriler ve istatistiklerle sıkça çalışan yaklaşık 5-8 araştırmadan oluşan bir ekip için olması gerekiyordu.

Veritabanı kurarken adlandırma kurallarıyla ilgili herhangi bir deneyiminiz var mı?

zaten anladığım bazı önemli şeyler:

  • sadece küçük harf kullan
  • boşlukları değil
  • ä, é, vb. gibi özel karakterler kullanmayın
  • sadece bir dil kullanın (önemsiz görünebilir, ancak biz uluslararasıyız)
  • tabloları ve sütunları her zaman tekil olarak adlandırın
  • veritabanındaki nesneleri adlandırmak için standart bir yol bulmak, örneğin topic_year_source_format

Özellikle son nokta zor. Kendi verilerimi saklayarak bazen çok büyük isimler alacağınızı fark ettim. Bu nedenle, bu bilgileri oldukça can sıkıcı olabilecek bu büyük isimleri yapmak yerine kolay erişilebilir bir meta verilerde saklamak daha uygun olur.

Yanıtlar:


3

Kulağa teknik sözleşmeler yapıldı gibi geliyor. Sorduğunuz sorunun doğru bir cevabı olduğunu düşünmüyorum, ancak size organizasyonumda kullanmak için ne bulduğumu anlatacağım.

Verileri gruplara göre düzenlemeyi tercih ederim, çünkü hepimizin bildiği gibi, bazen meta veriler doldurulmaz. Adlandırma kuralına en temel meta verilerin bir kısmını oluşturmanın çok faydalı olduğunu gördüm.

Başlamak için, kuruluşumun işlediği ana veri kategorilerini listeleyen bir e-tablo oluşturdum ve bunların her birine benzersiz bir iki harfli kod verdim. Elektronik tablonun ayrıca kategorinin bir açıklaması ve her bir kategoride bulunabilecek özellik örnekleri vardır. Bu e-tablo kuruluşumdaki herkes tarafından kullanılabilir ve bunu dışa aktarılan verilerin yanında eklerim.

Her isme iki harf kodu ve ardından bir alt çizgi ile başlıyorum. Elbette bu fikri genişletebilir ve veri yaratıcılarının adını da oluşturabilirsiniz. İsimleri kısa tutmaya ve yöntemlerinizi belgelemeye çalışın. İşte kullandığım kategorilere bazı örnekler:

BI - Bina İçi; BO - Sınırlar; CT - Kartografik; EL - Yükseklik Özellikleri; EM - Acil Müdahale; GE - Jeolojik; LT - Aydınlatma; PG - Sayfa Izgaraları ve Düzenleri; PL - Planimetrik; RA - Raster; RD - Referans Çizimi; SI - Saha İyileştirmeleri / Gerekçeleri; SU - Anket; UT - Yardımcı Programlar.


1
Bu geçerli bir yöntem, ama gerçekten kısaltmaları sevmiyorum. Bu elbette kişisel bir zevk meselesidir, ancak özellikle uluslararası bir ekipte iseniz, bu kısaltmalar herkesi karıştırabilir ve veritabanını kullanması gerektiğinde her zaman bir veri sözlüğüne ihtiyaç duyacaktır. PostgreSQL, yanılmıyorsam 64 harfli nesne adlarına izin verir. Bu alanı iyi kullanın ve bulabileceğiniz en açıklayıcı adları, herkesin anlayabileceği bir dilde oluşturun.
George Silva

Verileri kategorilere ayırma fikrini gerçekten seviyorum ve bunu meslektaşlarımla tartışacağım. Hala db içindeki veri adlandırma hakkında emin değilim. Argümanlarınız kullanılabilirlik için db içinde net isimler vermenin daha anlamlı olacağını anlamlıdır. Ancak meta veri belgesinin bu şekilde daha az kullanılabileceğinden korkuyorum. Verileri soyut sayılarla adlandırmanın kullanıcıları meta veri belgesine başvurmaya yönlendireceğini düşündüm ve bu da insanların günlük bazda başvurmaları gerektiğinden daha fazla meta veri bilgisi dolduracakları ve belge zaten açık ...
Dspanes

@Dspanes, bu ilginç bir argüman. Dediğim gibi, doğru cevap yok. Genel olarak, kullanıcıların meta verilere güvenmesini sağlamak için isimleri kasıtlı olarak kafa karıştırıcı yapma fikrinden hoşlandığımdan emin değilim ... yine de ilginç bir fikir.
Paul

@ Paul Evet bu biraz anlam ifade ediyor gibi görünüyor;) Ama şimdiye kadar sürdüğümden, insanlar sadece onlar için yararlı olanı kullanıyorlar. Ne kadar yararlı olurlarsa o kadar çok kullanırlar ve meta veriler ne kadar çok kullanırlarsa ... Şey, meta verilere bakacak bir kişiye sahip olmamamızdır, bu nedenle herkesin katkıda bulunduğu katılımcı bir yaklaşıma ihtiyacımız vardır. meta veri belgesi belki de fayda sağlayabilir, örneğin daha yeterli veri bulmanıza izin veren daha iyi arama ve filtre işlevlerine sahip olabilirsiniz ... ancak şüphesiz katılımı teşvik etmek için alternatif yaklaşımlar da düşünüyorum ...
Dspanes
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.