Konvensi penamaan untuk Database PostGIS? [Tutup]

Ditutup . Pertanyaan ini didasarkan pada pendapat . Saat ini tidak menerima jawaban.

Ingin meningkatkan pertanyaan ini? Perbarui pertanyaan sehingga dapat dijawab dengan fakta dan kutipan dengan mengedit posting ini .

Ditutup 2 tahun yang lalu .

Kami mulai membangun basis data dengan PostGIS. Basis data seharusnya untuk tim yang terdiri dari sekitar 5-8 peneliti yang sering bekerja dengan geodata dan statistik.

Adakah yang punya pengalaman dengan konvensi penamaan saat menyiapkan database?

beberapa hal penting yang sudah saya ketahui adalah:

gunakan hanya huruf kecil
use_underscores bukan spasi
jangan gunakan karakter khusus seperti ä, é, dll
hanya menggunakan satu bahasa (mungkin tampak sepele tapi kami internasional)
nama tabel dan kolom selalu dalam bentuk tunggal
menemukan cara standar untuk memberi nama objek dalam database yaitu topic_year_source_format

Terutama poin terakhir yang rumit. Menyimpan data saya sendiri saya tahu bahwa kadang-kadang Anda akan mendapatkan nama besar. Jadi apakah lebih baik menyimpan informasi ini dalam metadata yang mudah diakses daripada membuat nama-nama besar yang bisa sangat mengganggu.

postgis-2.0 naming-conventions

— Dspanes
sumber

Sepertinya Anda memiliki konvensi teknis yang berhasil. Saya tidak berpikir pertanyaan yang Anda tanyakan memiliki jawaban yang benar, tetapi saya akan memberi tahu Anda apa yang telah saya buat untuk digunakan dalam organisasi saya.

Saya lebih suka mengatur data berdasarkan kelompok karena, seperti kita semua tahu, kadang-kadang metadata tidak terisi. Saya menemukan membangun beberapa metadata paling dasar ke dalam konvensi penamaan menjadi sangat bermanfaat.

Untuk memulai, saya membuat spreadsheet yang mencantumkan kategori utama data yang ditangani organisasi saya dan memberikan masing-masing kode dua huruf yang unik. Spreadsheet juga memiliki deskripsi kategori dan contoh fitur yang dapat ditemukan dalam setiap kategori. Spreadsheet ini tersedia untuk semua orang di organisasi saya dan saya menyertakannya bersama data yang diekspor.

Saya memulai setiap nama dengan dua kode huruf diikuti dengan garis bawah. Anda tentu saja dapat memperluas ide ini dan membangun atas nama pembuat data juga. Usahakan agar namanya singkat dan dokumentasikan metode Anda. Berikut adalah beberapa contoh kategori yang saya gunakan:

BI - Bangunan Interior; BO - Batas; CT - Kartografi; EL - Fitur Ketinggian; EM - Tanggap Darurat; GE - Geologi; LT - Pencahayaan; PG - Grid dan Layout Halaman; PL - Planimetric; RA - Raster; RD - Gambar Referensi; SI - Perbaikan / Alasan Situs; SU - Survei; UT - Utilitas.

— Paul
sumber

Ini adalah metode yang valid, tetapi saya benar-benar tidak suka singkatan. Ini tentu saja masalah selera pribadi, tetapi khususnya jika Anda berada di tim internasional, singkatan-singkatan ini dapat membingungkan semua orang dan orang akan selalu membutuhkan kamus data setiap kali ia perlu menggunakan database. PostgreSQL memungkinkan, jika saya tidak salah, 64 nama objek huruf. Manfaatkan ruang itu dan buat nama deskriptif yang bisa Anda temukan, dalam bahasa yang bisa dipahami semua orang.

— George Silva

Saya sangat suka ide mengategorikan data dan saya akan membahas hal ini dengan kolega saya. Masih saya tidak yakin tentang penamaan data di dalam db. Argumen Anda sangat masuk akal bahwa untuk kegunaan akan lebih baik untuk memberikan nama yang jelas di dalam db. Tetapi saya khawatir dokumen metadata mungkin kurang digunakan seperti ini. Saya berpikir bahwa penamaan data dengan angka abstrak akan mendorong pengguna untuk merujuk ke dokumen metadata dan dengan ini berkontribusi lebih banyak dengan cara orang mengisi lebih banyak informasi metadata karena mereka harus merujuknya pada basis harian dan dokumen tersebut adalah sudah buka ...

— Dspanes

@Dspanes, itu argumen yang menarik. Seperti yang saya katakan, tidak ada jawaban yang benar. Secara umum saya tidak yakin saya suka ide membuat nama-nama sengaja membingungkan sehingga membuat pengguna bergantung pada metadata ... itu adalah ide yang menarik.

— Paul

@ Paul Ya sepertinya agak berarti aku tahu;) Tapi dari apa yang telah saya ketahui sejauh ini, orang hanya menggunakan apa yang bermanfaat bagi mereka. Semakin bermanfaat semakin banyak mereka menggunakannya dan semakin banyak mereka menggunakan semakin baik metadata yang didapat ... Masalahnya adalah kita tidak memiliki seseorang untuk mengurus metadata sehingga kita membutuhkan pendekatan partisipatif di mana setiap orang berkontribusi. dokumen metadata mungkin dapat membawa manfaat juga misalnya Anda dapat memiliki fungsi pencarian dan filter yang lebih baik yang memungkinkan untuk menemukan data yang lebih memadai ... tetapi tanpa ragu saya juga memikirkan pendekatan alternatif untuk mendorong partisipasi ...

— Dspanes