¿Cómo controlar la versión del esquema PostgreSQL con comentarios?

9

Control de versiones de la mayor parte de mi trabajo con Git : código, documentación, configuración del sistema. Puedo hacerlo porque todo mi valioso trabajo se almacena como archivos de texto.

También he estado escribiendo y tratando con muchos esquemas SQL para nuestra base de datos Postgres. El esquema incluye vistas, funciones SQL, y escribiremos funciones de Postgres en lenguaje de programación R (a través de PL / R ).

Estaba tratando de copiar y pasar el esquema de fragmentos que escribimos yo y mis colaboradores, pero me olvido de hacerlo. La copia y la acción pasada son repetitivas y propensas a errores.

El método pg_dump / pg_restore no funcionará porque pierde comentarios.

Idealmente, me gustaría tener alguna forma de extraer mi esquema actual en un archivo o archivos y preservar los comentarios para poder controlar la versión.

¿Cuál es la mejor práctica para el esquema de control de versiones con comentarios?

postgresql schema version-control

— Aleksandr Levchuk
fuente

2

No creo que la pregunta sea específica de psql. ¿Has leído algunas de las respuestas en SO stackoverflow.com/… ? Puede haber algo para ti.

— DrColossos

@DrColossos: algunas de esas preguntas son buenos candidatos para la migración.

— CoderHawk

@DrColossos está COMMENT ONdisponible en un entorno no postgres? No creo que sea SQL estándar. lo que significa que esto podría ser postgres específico.

— xenoterracida

@xenoterracide Tienes razón, estaba hablando más sobre el problema del versionado de una base de datos en sí misma

— DrColossos

9

¿Por qué no COMMENT ONlos distintos SCHEMAcomponentes? De esa manera, sus comentarios están en el esquema y serán rechazados.

COMENTARIO almacena un comentario sobre un objeto de base de datos.

Para modificar un comentario, emita un nuevo comando COMENTARIO para el mismo objeto. Solo se almacena una cadena de comentarios para cada objeto. Para eliminar un comentario, escriba NULL en lugar de la cadena de texto. Los comentarios se descartan automáticamente cuando se cae el objeto.

— xenoterracida
fuente

Realmente útil, pero no quiero marcar esto como Respuesta todavía porque espero obtener una respuesta de mejores prácticas.

— Aleksandr Levchuk

2

Los esquemas de control de versiones siempre han sido problemáticos para mí. Generalmente controlo la versión del esquema generado por la herramienta de modelado de datos que estoy usando. El modelo también está controlado por la versión. Utilizo diferencias entre el esquema actual y el anterior para construir el parche requerido para actualizar el esquema. Algunas herramientas de modelado crean scripts de actualización de esquema utilizables. Los scripts de actualización también están controlados por la versión.

Ocasionalmente veo scripts que están destinados a volcar el esquema en un formato adecuado para regenerar el esquema. Uno de estos puede ser lo que estás buscando. Algunas de las herramientas de modelado y consulta son capaces de crear scripts de regeneración de esquemas a partir de un esquema existente. Si puede escribir esto, puede proporcionarle un archivo adecuado para el control de versiones.

— BillThor
fuente

2

Una alternativa (o puede combinarlos) a mi propuesta anterior es escribir su código SQL en su editor (IDE) y guardar los archivos, y confirmarlos en su VCS, después de eso ejecute el código en la base de datos usando psql -1f. De esta manera, el código es controlado por la versión antes de ser ejecutado.

— xenoterracida
fuente

"De esta manera, el código es controlado por la versión antes de ser ejecutado". Y debería ser.

— Mike Sherrill 'Cat Recall'

@catcall sí, pero si lees la publicación de operaciones, no creo que ese sea el caso.

— xenoterracide

Desafortunadamente, no es el caso en la mayoría de los lugares que he visto. Pero esa es la única forma de garantizar que el código que prueba y QA es el mismo código que pasa a producción. La idea de que la base de datos "verdadera" está en el VCS, no en el DBMS, no está muy extendida.

— Mike Sherrill 'Cat Recall'

0

Estoy trabajando en un proyecto similar. Esta es mi propuesta de diseño:

Comente los objetos de la base de datos de forma regular, digamos cada dos semanas o dos veces al mes.
do pg_dump all (sí, obtenga todo para asegurarse de obtener todos los pequeños detalles y relaciones). Nómbrelos por aaaammdd-VERSION.dump
Si usa Git, use un complemento para archivos grandes
Si no usa un repositorio, cree una tabla simple en formato de texto .CSV como la tabla a continuación:

version | file name | date | description | 1.0 | yyyymmdd-v10.dump | yyyymmdd | new version of user table | 1.1 | backupDB-v11.dump | yyyymmdd | normalized reports tables |
Al mantener una relación en el archivo CSV de los volcados generados por nombre de archivo, puede rastrearlos de alguna manera fácilmente y asegurarse de que la restauración funcionará porque eliminó absolutamente todo.

Hoy en día, cualquier almacenamiento en la nube o en el sitio no debería ser tan costoso incluso si se habla de TB de datos. Hay algunos furiosos de 700 a 1000 USD con hasta 16 TB .

Incluso puede ahorrar $$$ mucho más si se muda a una nube de almacenamiento como el tipo más popular de AWS S3

Si un buen diseño y los estándares de la organización se definen para realizar un seguimiento de toda la infraestructura y los activos de TI, no debería ser doloroso una vez implementado, puede ser relativamente simple y le ahorrará los dolores de configuración y lo más importante ...

— Andres Leon Rangel
fuente