Over the last two years I have been working lot on improving the tooling and processes related to database development at where I work. One concept born out of this work is what we have started calling a “Database-as-a-Code” model. Originally the idea was to introduce some of the good practices, such as version control, build automation and unit testing to database development. Over the time it has evolved to include even more, in an effort to break down traditional silos between software developers, database developers and the operations people.
In this post I’ll describe some of the decisions we made and the steps we have taken in our Database DevOps journey.
PASS Summit 2017 is now well behind us and there has been good time to reflect on this years conference. First of all, I have to say that Seattle as a venue is a good choice, even though for some of us that is a long way to travel. To me, it is about 20 hours from SEA-TAC to my home with the flights and driving, doable but not necessarily pleasant. As for the conference itself, I feel that it keeps getting better every year. It has definitely changed a quite a bit from my first Summit back in 2013. But so is the world where data platform professionals live, and the products we work with.
Here are some highlights from the PASS Summit 2017!
This year I didn’t write my usual daily blog posts during the PASS Summit 2016 as I felt it to be bit too much work with the long days and bit of a jet lag with the 10 hour time difference. Instead I decided to write a post summarizing my experience of the event. Every year, when deciding on what pre-con sessions to take and what regular sessions to attend to I try to think of a theme. This year I decided to go with Big Data and Analytics, as that’s an area of Microsoft Data Platform I’m not terribly familiar with. It was also a good choice because with SQL Server 2016 we’re seeing a huge number of improvements on technologies involved with these topics and there were quite a few sessions regarding these.
One of the new interesting features in SQL Server 2016 is the system-versioning with a catchy name, Temporal Tables. The name of the feature offers a hint to its purpose, to collect and to keep historical information about the data changes inside the database over a period of time. Instead of having just the latest data, we now have a way to know what it has been in any previous point in time. The most obvious use case for Temporal Tables is auditing, or at least it is to me, but they can be used for other purposes as well. Some examples are going back in time in case you need to perform a data recovery from an error or a data change operation gone bad, or you might want to use it for reporting purposes.
There are few things about the Temporal Tables that are good to know. First of all the work needed to keep track of the changes is done by the database engine when the system-versioning feature is enabled. Another thing some of you might appreciate is that the feature is available also in Standard Edition. And finally my favorite, it’s actually rather easy to start using the system-versioning as we will discover shortly.
Just finished watching the Data Driven event that was broadcasted live from New York earlier today. As expected there was a lot of information about SQL Server 2016 and quite a few visitors telling how their companies used Microsoft SQL Server in their daily business. And these were some big businesses, having impressive amounts of data and transactions to handle. With SQL Server 2016 Microsoft is giving us a feature packed and complete data platform to work with.