Hacker News Reader

Comment by Duff | Hacker News Reader

I think that with a modern database like SQL Server, the old-school "high priest" DBA is obsolete.

But... if you don't have someone dedicated to thinking about database issues, you need to treat database changes just like your code. It needs to be in a repository, it needs to be reviewed, and you need a change management regime.

From a anecdotal POV, I've noticed that many folks have a good process (or at least a consensus approach) to managing their code... but the database is often a red-headed stepchild that doesn't get the attention it deserves.

View on HN

but the database is often a red-headed stepchild that doesn't get the attention it deserves

On my last three major projects, I have committed to devoting the proper level of attention to the database, with automatically building databases in some environments, scripted scheme changes and seed data loading as part of the mainline code base, etc. and I have found the difference to be immense in practical terms. I can move more quickly, more safely, and have a better quality of life as a developer.

One of the best returns on (effort) invested I have ever seen.

I definitely agree. We have been using fluent migrator (https://github.com/schambers/fluentmigrator) for our .net based projects at work for database migrations and versioning

Thanks. Fluent Migrator looks pretty cool. I've been rolling my own stuff as-needed. As a result, it has evolved into something pretty useful for the problems I've encountered so far, but does nothing outside of what I've already thought of. I can see using the migrator as a good jumping off point.

Sure, I wasn't suggesting a high priest. Maybe more a 'faculty advisor' dba? Just someone keeping an eye on the higher level problems (having the right Nagios alerts set up, keeping an eye on how long reindexing is taking and scheduling downtime according, disaster recovery planning, putting in the POs for new drives). That's even if you treat writing queries and schema changes like part of the code, it's a dynamic system. But I completely agree on treating DB changes like code changes, I think DevOps is a good approach.

Same as with a modern language, the old-school "high priest" developer is obsolete.

Thankfully, with Liquibase [1] and others like it, developers are starting to think about database change management.

I absolutely despise writing liquibase changesets, but I know how important they are.

[1] http://www.liquibase.org/

Reply on news.ycombinator.com