Database version control without pain

Very good talk on solutions available for database version control. Have got some good ideas on how to improve our phing deployments scripts

Great talk. Nice to be introduced to new tools. No more old bikes!!

Nice talk about version control of database(structure) touching on the most important problems that you will run in. The topic of solving merge conflicts in database changes was however underexposed and imo deserves more attention and in-depth exploration.

Good stuff ! Nice to see that there are tools out there that can handle SQL delta data.

Decent slides, nice overview & summary. Very accessible talk.

Good talk! Only a bit of deception to hear that there still no all-in-one solution for this versioning issue!

Had read the slides from a previous conference, but it was good to see the presentation as Harrie filled in some of the gaps. Nice and confident in his delivery and he kept a decent pace. Would have liked to have seen a bit more about the Doctrine stuff, but he covered a lot for a 45 minute slot. Technical examples were easy to follow as well.

This was a nice talk, and the presenter came well prepared. Too bad I didn't hear about some silver bullet, but hey, that's not his fault :)

Liked the summary of the different strategies for database version control. An important topic oft ignored. Nice to see the simple patching system is what we use at Studio 24. From what Harrie says seems to be keep it simple = good. Rob Allen's Akrabat_Db_Schema_Manager is something I really need to check out though.

Good talk, good speaker. Harrie touched the real problem once (the new "type" table in a branche and a new "type" table in trunk which will collide when merging), but he never came with a solution/direction to that problem, that would've given it more depth. The delta's/migration/db patches itself aren't rocket science of course.

I wouldn't mind more normal slides and less photo's with some kind of "metaphor", bit too much for me.

good speaker good content. Especially since I followed Harrie twittering about his timing worries ;) My tips : shorten the intro about the need for versioning. To much slides about numbering etc. And if possible try adding a part about logic that lives in db's. I do know it is bad practize to have logic that has logic in db only but systems like drupal and wordpress 3 do use it. Same goes for stored procedures etc.

Same as Miljar

Clear talk about the different techniques and strategies when performing db deployments and migrations.

Tools discussed: Liquibase, DB Deploy

Good talk, nothing much to add to it really

Nice presentation and I had a great talk with Harrie afterwards. Although I don't know about anything that wasn't covered, I do have some doubts on whether Harrie covered everything (relevant) there is to know about the subject. I still have the feeling something is missing.

Very well done. Many small improvements compared to the talk he held at PFCongres 2010. Good to see that Liquibase was covered.

I liked the presentation. I think there is still pain involved somehow. The "without pain" in the title sounds promising, but I think with any of the solutions proposed in this talk, we are exchanging one type of pain for another.

Still I could make quite a few notes of techniques I didn't yet bother to investigate and that I might look at as a result of attending. Phing, Liquibase. Thanks Harrie!

Good speaker but I was a little disappointed by the solutions.

Good presentation, just a shame the best solution is still roll your own :)

Harrie definitely showed us that database schema's can be controlled, the talk had a nice build-up. It started with fairly simple solutions and as the talk continued you got the picture how these can become more advanced life savers. All the questions that came in mind got answered while the talk progressed, and at the end I got the whole picture without asking a single question.

Interesting. We already have the in house script which seems the best. We don't have any branching problems because [we don't use so many branches :))] we have the names of the patches generated from timestamp. pretty small chance that two developers will create a patch in the exact same second.

Nice talk illustrating the problem and possible methodologies for getting around them.