Come controllare la versione dello schema PostgreSQL con commenti?

9

Controllo versione gran parte del mio lavoro con Git : codice, documentazione, configurazione del sistema. Sono in grado di farlo perché tutto il mio prezioso lavoro è archiviato come file di testo.

Ho anche scritto e trattato molti schemi SQL per il nostro database Postgres. Lo schema include viste, funzioni SQL e scriveremo le funzioni di Postgres nel linguaggio di programmazione R (via PL / R ).

Stavo cercando di copiare e incollare lo schema di blocchi che io e i miei collaboratori scriviamo, ma mi dimentico di farlo. La copia e l'azione passata sono ripetitive e soggette a errori.

Il metodo pg_dump / pg_restore non funzionerà perché perde commenti.

Idealmente, vorrei avere un modo per estrarre il mio schema attuale in uno o più file e conservare i commenti in modo da poter eseguire il controllo della versione.

Qual è la procedura ottimale per controllare lo schema di versione con commenti?

postgresql schema version-control

— Aleksandr Levchuk
fonte

2

Non penso che la domanda sia specifica per psql. Hai letto alcune delle risposte su SO stackoverflow.com/… ? Potrebbe esserci qualcosa per te.

— DrColossos,

@DrColossos - alcune di queste domande sono buoni candidati alla migrazione.

— CoderHawk,

@DrColossos è COMMENT ONdisponibile in un ambiente non postgres? Non penso che sia SQL standard. il che significa che questo potrebbe essere specifico per Postgres.

— xenoterracide,

@xenoterracide Hai ragione, stavo parlando più del problema del controllo delle versioni di un database stesso

— DrColossos,

9

Perché non COMMENT ONi vari SCHEMAcomponenti, in questo modo i tuoi commenti sono nello schema e verranno scaricati.

COMMENT memorizza un commento su un oggetto database.

Per modificare un commento, emettere un nuovo comando COMMENT per lo stesso oggetto. Viene memorizzata una sola stringa di commento per ciascun oggetto. Per rimuovere un commento, scrivere NULL al posto della stringa di testo. I commenti vengono eliminati automaticamente quando l'oggetto viene rilasciato.

— xenoterracide
fonte

Veramente utile, ma non desidero contrassegnarlo come Risposta solo perché spero di ottenere una risposta sulle migliori pratiche.

— Aleksandr Levchuk,

2

Gli schemi di controllo della versione sono sempre stati problematici per me. In genere controllo la versione dello schema generato dallo strumento di modellazione dei dati che sto utilizzando. Il modello è anche controllato in versione. Uso le differenze tra lo schema corrente e quello precedente per creare la patch richiesta per aggiornare lo schema. Alcuni strumenti di modellazione creano script di aggiornamento dello schema utilizzabili. Gli script di aggiornamento sono anche controllati dalla versione.

Di tanto in tanto vedo degli script che hanno lo scopo di scaricare lo schema in un formato adatto a rigenerare lo schema. Uno di questi potrebbe essere quello che stai cercando. Alcuni strumenti di modellazione e query sono in grado di creare script di rigenerazione dello schema da uno schema esistente. Se riesci a scrivere questo, potrebbe darti un file adatto per il controllo della versione.

— BillThor
fonte

2

Un'alternativa (o puoi combinarli) alla mia proposta precedente è quella di scrivere il tuo codice SQL nel tuo editor (IDE) e salvare i file e trasferirli nel tuo VCS, dopo di che esegui il codice sul database usando psql -1f. In questo modo il codice è controllato dalla versione prima di essere mai eseguito.

— xenoterracide
fonte

"In questo modo il codice è controllato dalla versione prima di essere mai eseguito." E dovrebbe essere.

— Mike Sherrill 'Cat Recall'

@catcall sì, ma se leggi il post operativo, non penso che sia così.

— xenoterracide

Purtroppo non è il caso nella maggior parte dei posti che ho visto. Ma questo è l'unico modo per garantire che il codice testato e il QA siano gli stessi codici che passi alla produzione. L'idea che il database "vero" sia nel VCS, non nel DBMS, non è molto diffusa.

— Mike Sherrill 'Cat Recall'

0

Sto lavorando in un progetto simile. Questa è la mia proposta di design:

Commenta gli oggetti DB su base regolare, diciamo ogni due settimane o due volte al mese.
fai pg_dump all (sì ottieni tutto per assicurarti di avere tutti i piccoli dettagli e relazioni). Denominali con yyyymmdd-VERSION.dump
Se usi Git usa un plugin per file di grandi dimensioni
Se non si utilizza un repository, creare una semplice tabella in formato .CSV di testo come la tabella seguente:

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 |
mantenendo una relazione nel file CSV dei dump generati per nome file, è possibile rintracciarli in qualche modo facilmente e assicurarsi che il ripristino funzionerà perché è stato scaricato tutto.

Al giorno d'oggi qualsiasi archivio cloud o archiviazione sul sito non dovrebbe essere così costoso anche se si parla di TB di dati. ci sono alcune furie da 700 a 1000 USD con un massimo di 16 TB .

Puoi persino risparmiare molto di più se passi a un cloud di archiviazione come quello del più popolare AWS S3

Se una buona progettazione e gli standard dell'organizzazione sono definiti per tenere traccia di tutte le infrastrutture e le risorse IT, non dovrebbe essere doloroso una volta implementato, può essere relativamente semplice e ti farà risparmiare i problemi di configurazione e, soprattutto, il tempo ...

— Andres Leon Rangel
fonte