Convenzioni di denominazione per il database PostGIS? [chiuso]

Stiamo iniziando a costruire un database con PostGIS. Il database dovrebbe essere per un team di circa 5-8 ricerche che lavorano frequentemente con geodati e statistiche.

Qualcuno ha esperienza con le convenzioni di denominazione durante l'impostazione di un database?

alcune cose importanti che ho già capito sono:

usa solo lettere minuscole
use_underscores non spazi
non usare caratteri speciali come ä, é, ecc
usa solo una lingua (potrebbe sembrare banale ma siamo internazionali)
tabelle e colonne dei nomi sempre in singolare
trova un modo standardizzato per nominare gli oggetti nel database, ad esempio topic_year_source_format

Soprattutto l'ultimo punto è complicato. Memorizzando i miei dati ho riconosciuto che a volte otterrai nomi enormi. Quindi sarebbe complicato archiviare queste informazioni in metadati facilmente accessibili invece di creare questi nomi enormi che possono essere abbastanza fastidiosi.

postgis-2.0 naming-conventions

— Dspanes
fonte

Sembra che tu abbia elaborato le convenzioni tecniche. Non credo che la domanda che stai ponendo abbia una risposta corretta, ma ti dirò cosa ho escogitato per l'uso nella mia organizzazione.

Preferisco organizzare i dati per gruppi perché, come tutti sappiamo, a volte i metadati non vengono compilati. Ho trovato molto utile la creazione di alcuni dei metadati di base nella convenzione di denominazione.

Per iniziare, ho creato un foglio di calcolo che elenca le principali categorie di dati gestite dalla mia organizzazione e ho assegnato a ciascuna di esse un codice univoco di due lettere. Il foglio di calcolo ha anche una descrizione della categoria ed esempi di funzionalità che possono essere trovate all'interno di ciascuna categoria. Questo foglio di calcolo è disponibile per tutti nella mia organizzazione e lo includo insieme ai dati esportati.

Comincio ogni nome con il codice di due lettere seguito da un trattino basso. Ovviamente potresti ampliare questa idea e creare anche il nome di creatori di dati. Cerca di mantenere i nomi brevi e documenta i tuoi metodi. Ecco alcuni esempi delle categorie che utilizzo:

BI - Interno di edificio; BO - Confini; CT - Cartografico; EL - Caratteristiche di elevazione; EM - Risposta di emergenza; GE - Geologico; LT - Illuminazione; PG - Griglie e layout di pagina; PL - Planimetrico; RA - Raster; RD - Disegno di riferimento; SI - Miglioramenti / motivi del sito; SU - Sondaggio; UT - Utilità.

— Paolo
fonte

Questo è un metodo valido, ma in realtà non mi piacciono le abbreviazioni. Questa è ovviamente una questione di gusti personali, ma specialmente se fai parte di un team internazionale, queste abbreviazioni possono confondere tutti e uno avrà sempre bisogno di un dizionario di dati ogni volta che dovrà usare il database. PostgreSQL consente, se non sbaglio, nomi di oggetti di 64 lettere. Fai buon uso di quello spazio e crea i nomi più descrittivi che puoi trovare, in una lingua che tutti possano capire.

— George Silva,

Mi piace molto l'idea di classificare i dati e ne discuterò con i miei colleghi. Non sono ancora sicuro di nominare i dati all'interno del db. Le tue argomentazioni hanno perfettamente senso che, per l'usabilità, sarà opportuno dare nomi chiari all'interno del db. Ma temo che il documento sui metadati possa essere meno utilizzato in questo modo. Ho pensato che la denominazione dei dati con numeri astratti avrebbe spinto gli utenti a fare riferimento al documento sui metadati e con questo contribuire maggiormente ad esso in modo tale che le persone compilino più informazioni sui metadati poiché devono fare riferimento ad essi su base giornaliera e il documento è già aperto ...

— Dspanes il

@Dspanes, questo è un argomento interessante. Come ho detto, non c'è una risposta giusta. In generale non sono sicuro che mi piace l'idea di confondere intenzionalmente i nomi in modo da fare in modo che gli utenti facciano affidamento sui metadati ... è comunque un'idea interessante.

— Paul

@Paul Sì, sembra un po 'meschino, lo so;) Ma da quello che ho espirato finora, le persone usano solo ciò che è utile per loro. Più sono utili, più lo usano e più usano e meglio potrebbero ottenere i metadati ... Il fatto è che non abbiamo una persona che si prenda cura dei metadati, quindi abbiamo bisogno di un approccio partecipativo in cui tutti contribuiscano. il documento sui metadati potrebbe anche portare benefici, ad esempio potresti avere migliori funzioni di ricerca e filtro che consentono di trovare dati più adeguati ... ma senza dubbio sto anche pensando ad approcci alternativi per favorire la partecipazione ...

— Dspanes