StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
17961454
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-07-31T04:10:46.720
FavoriteCount
0
LastActivityDate
2013-07-31T04:10:46.720
LastEditDate
LastEditorUserId
0
OwnerUserId
2566107
ParentId
17960955
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
Well, your question is actually quite relevant to any database developer, and, if I understand it correctly, there is another way to get to your desired results. One interesting thing to mention is that your idea of separating different changes into different files is the concept of migrations of Ruby On Rails. You might even be able to use the rake utility to keep track of a workflow like yours. But now to what I think migh be your solution. PostgreSQL, and others to be sincere, have specific utilities to handle data and schemas like what you probably need. The <a href="http://www.postgresql.org/docs/9.2/static/app-pg-dumpall.html" rel="nofollow">pg_dumpall</a> command-line executable will dump the whole database into a file or the console, in a way that the <a href="http://www.postgresql.org/docs/9.2/static/app-psql.html" rel="nofollow">psql</a> utility can simply "reload" into the same, or into another (virgin) database. So, if you want to keep only the current schema (no data!) of a running database cluster, you can, as the postgres-process owner user: <pre><code>$ pg_dumpall --schema-only > schema.sql </code></pre> Now the schema.sql will hold exactly the same users/databases/tables/triggers/etc, but not data. If you want to have a "full-backup" style dump (and that's one way to take a full backup of a database), just remove the "--schema-only" option from the command line. You can reload the file into another (should be virgin, you might mess up a database with other data doing this): <pre><code>$ psql -f schema.sql postgres </code></pre> Now if you only want to dump one database, one table, etc. you should use the pg_dump utility. <pre><code>$ pg_dump --schema-only <database> > database-schema.sql </code></pre> And then, to reload the database into a running postgresql server: <pre><code>$ psql <database> < database-schema.sql </code></pre> As for version control, you can just keep the schema.sql file under it, and just dump the database again into the file before every vc commit. So at some particular version control state will you have the code and the working database schema that goes with it. Oh, and all the tools I mentioned are free, and pg_dump and pg_dumpall come with the standard PostgreSQL installation. Hope that helps, Marco
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POPostgreSQL development workflow
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USMarco Poli
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.