3 ms·
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
by Duff 15y ago
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.
- gaius 15y agoSame as with a modern language, the old-school "high priest" developer is obsolete.
- reginaldo 15y agoThankfully, 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/ http://www.liquibase.org/
- 3am 15y agoSure, 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.
- MartinCron 15y agobut 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.
- lukencode 15y agoI definitely agree. We have been using fluent migrator (https://github.com/schambers/fluentmigrator https://github.com/schambers/fluentmigrator) for our .net based projects at work for database migrations and versioning
- MartinCron 15y agoThanks. 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.