Convenciones de nomenclatura para la base de datos PostGIS? [cerrado]

Estamos comenzando a construir una base de datos con PostGIS. Se supone que la base de datos es para un equipo de aproximadamente 5-8 investigaciones que trabajan frecuentemente con geodatos y estadísticas.

¿Alguien tiene experiencia con las convenciones de nomenclatura al configurar una base de datos?

Algunas cosas importantes que ya descubrí son:

usar solo minúsculas
use_underscores no espacios
no use caracteres especiales como ä, é, etc.
solo uso un idioma (puede parecer trivial pero somos internacionales)
nombrar tablas y columnas siempre en singular
encontrar una forma estandarizada de nombrar los objetos en la base de datos, es decir topic_year_source_format

Especialmente el último punto es complicado. Al almacenar mis propios datos, reconocí que a veces obtendrás nombres enormes. Entonces, sería mejor almacenar esta información en metadatos que sean de fácil acceso en lugar de crear estos nombres enormes que pueden ser bastante molestos.

postgis-2.0 naming-conventions

— Dspanes
fuente

Parece que tienes las convenciones técnicas resueltas. No creo que la pregunta que haga tenga una respuesta correcta, pero le diré lo que se me ocurrió para usar en mi organización.

Prefiero organizar los datos por grupos porque, como todos sabemos, a veces los metadatos simplemente no se completan. He encontrado que construir algunos de los metadatos más básicos en la convención de nombres es muy beneficioso.

Para comenzar, creé una hoja de cálculo con una lista de las principales categorías de datos que maneja mi organización y le di a cada una un código único de dos letras. La hoja de cálculo también tiene una descripción de la categoría y ejemplos de características que se pueden encontrar dentro de cada categoría. Esta hoja de cálculo está disponible para todos en mi organización y la incluyo junto con los datos exportados.

Comienzo cada nombre con el código de dos letras seguido de un guión bajo. Por supuesto, podría ampliar esta idea y construir también en nombre de los creadores de datos. Intenta mantener los nombres cortos y documenta tus métodos. Aquí hay algunos ejemplos de las categorías que uso:

BI - Interior del edificio; BO - Límites; CT: cartográfica; EL - Características de elevación; EM - Respuesta de emergencia; GE: geológico; LT - Iluminación; PG - Cuadrículas y diseños de página; PL - Planimétrico; RA - Ráster; RD - Dibujo de referencia; SI - Mejoras del sitio / Terrenos; SU - Encuesta; UT - Utilidades.

— Pablo
fuente

Este es un método válido, pero realmente no me gustan las abreviaturas. Esto es, por supuesto, una cuestión de gusto personal, pero especialmente si está en un equipo internacional, estas abreviaturas pueden confundir a todos y uno siempre necesitará un diccionario de datos cuando necesite usar la base de datos. PostgreSQL permite, si no me equivoco, nombres de objetos de 64 letras. Haga buen uso de ese espacio y cree los nombres más descriptivos que pueda encontrar, en un idioma que todos puedan entender.

— George Silva

Realmente me gusta la idea de clasificar los datos y discutiré esto con mis colegas. Todavía no estoy seguro de nombrar los datos dentro de la base de datos. Sus argumentos tienen todo el sentido de que para la usabilidad será mejor dar nombres claros dentro de la base de datos. Pero me temo que el documento de metadatos puede ser menos utilizado así. Pensé que nombrar los datos con números abstractos conduciría a los usuarios a referirse al documento de metadatos y con esto contribuiría más de una manera en que las personas completen más información de metadatos, ya que tienen que consultarlo diariamente y el documento es ya abierto ...

— Dspanes

@Dspanes, ese es un argumento interesante. Como dije, no hay una respuesta correcta. En general, no estoy seguro de que me guste la idea de hacer que los nombres sean intencionalmente confusos para que los usuarios confíen en los metadatos ... aunque es una idea interesante.

— Paul

@Paul Sí, parece un poco malo, lo sé;) Pero por lo que he experimentado hasta ahora, la gente solo usa lo que es útil para ellos. Cuanto más útil sea, más lo usen y más lo usen, mejor podrían ser los metadatos ... El hecho es que no tenemos una persona que se encargue de los metadatos, por lo que necesitamos un enfoque participativo en el que todos contribuyan. el documento de metadatos también podría traer beneficios, por ejemplo, podría tener mejores funciones de búsqueda y filtro que permitan encontrar datos más adecuados ... pero sin duda también estoy pensando en enfoques alternativos para fomentar la participación ...

— Dspanes