September 19, 2019 at 12:00 am
Comments posted to this topic are about the item A Good Reason to use a VCS
September 19, 2019 at 12:41 pm
There's been discussions about putting the databases under source control where I work. But I don't think that the databases have been put into any source control. As a C# developer, our code is in source control. I took over maintenance of a contractor developed system which uses stored procedures extensively; there is no embedded SQL in the code. Looking at what the code does is impossible to determine without access to the stored procedures. I got tired of switching from Visual Studio to SSMS to look at the code, so I scripted the database and added the SQL folder to the C# project; that way, I can examine the stored procedure from Visual Studio instead of switching to the database. As a result of the scripting, I also added the scripts to the database.
At other places where I worked, data that was loaded into lookup or reference tables were added to source control. I don't know if the databases were in source control.
September 19, 2019 at 1:27 pm
We're going through this process at the moment, but the issue isn't purely source control
I have maybe 400 databases to create repositories, clone and link to GIT... i'm about 40 databases in at the moment (our key ones) - but we need the full Devops cycle and stop people deving on live and use something like provisioning, build pipelines, and a full CI lifecycle to make it work
the biggest issue is "people".. a lot of people can see source control and devops as an obstruction to getting their job done (when they come running for restore of a proc from a 400GB database it kinda changes their mind)
MVDBA
September 19, 2019 at 2:30 pm
The biggest reason I have for not having a VCS for DB's right now is that MS doesn't include on standard with SQL Server.
September 19, 2019 at 2:36 pm
The biggest reason I have for not having a VCS for DB's right now is that MS doesn't include on standard with SQL Server.
Not sure what you mean here? Do you mean the tooling doesn't link to a VCS? ADS does, and certainly you can script out from SSMS and store that in a folder linked to a VCS. While I do think the tooling is poor, which is why Redgate and others have built tools, the habits we've built over the years to edit from the OE by clicking Modify. That's a bad habit.
The other thing is that many developers use a client like SourceTree or GitKrakken to manage their VCS outside the IDE. It's a skill and a habit to build, but it works well with SSMS. When I started doing this, I used the VSS client and Enterprise Manager, saving code to the file system and committing it.
September 19, 2019 at 4:01 pm
ZZartin wrote:The biggest reason I have for not having a VCS for DB's right now is that MS doesn't include on standard with SQL Server.
Not sure what you mean here? Do you mean the tooling doesn't link to a VCS? ADS does, and certainly you can script out from SSMS and store that in a folder linked to a VCS. While I do think the tooling is poor, which is why Redgate and others have built tools, the habits we've built over the years to edit from the OE by clicking Modify. That's a bad habit.
The other thing is that many developers use a client like SourceTree or GitKrakken to manage their VCS outside the IDE. It's a skill and a habit to build, but it works well with SSMS. When I started doing this, I used the VSS client and Enterprise Manager, saving code to the file system and committing it.
That is basically what I mean, SQL Server does not come with a VCS out of the box. And while I realize that you can hook Visual Studio and Git into it(or other tools) that's a lot of extra hoops to jump through for what should just be standard.
September 19, 2019 at 4:36 pm
I completely agree it should be built in, especially as VS includes VCS support. However, I'm not sure the hoops are a good reason to not use a VCS.
September 20, 2019 at 7:07 am
when they come running for restore of a proc from a 400GB database it kinda changes their mind
Forbit them to create any table in the primary filegroup, than this is not a problem (you can do a partial restore of only one or a few filegroups, the but the [PRIMARY], where the sys tables / procedures etc. are stored, will ALWAYS be restored.
Of course it is a little bit (or on big databases much more) work to move all tables into another filegroup (by recreating any index and specifying the ON [<FG>] clausel), but in long term it helps a lot.
PS: *smart aleck on*
regarding "every Editor on this planet has File | Save" - vi or (if you like DOS more than Unix / Linux) edline have no File | Save. To be honest they have not any menue at all, since they are more commandline based editors 🙂
*smart aleck off*
God is real, unless declared integer.
September 20, 2019 at 8:05 am
Hi thomas
we're restoring to a dev server, so filegroup restores would be a nightmare.
i've found the best way is redgate source control and GIT with sql compare if needed
MVDBA
September 23, 2019 at 2:33 pm
PS: *smart aleck on*
regarding "every Editor on this planet has File | Save" - vi or (if you like DOS more than Unix / Linux) edline have no File | Save. To be honest they have not any menue at all, since they are more commandline based editors 🙂
*smart aleck off*
If you are using edline to fix T-SQL scripts, you win. Otherwise, every editor that is in use by normal people has FILE|SAVE
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply