I agree with this. Currently I am trying to untangle an old .NET framework backend from an old Microsoft SQL server. There are a ton of stored procedures that the old code relied on for business logic, but there isn't an easy way to keep those version controlled or even know what code uses what stored procedures. As a result of the mayhem, all new SQL I write is version controlled in the source code and doesn't touch stored procedures. It just keeps things simpler because Visual Studio can tell me exactly how many references a string of SQL has and where they are (This seems clunky to me so I am trying to find a different place to store queries).
I think that there is a balance of what should be in SQL and what should be in another language. I like this article overall though because I think it is important not to ignore SQL and SQL functions are absolutely perfect for certain applications
There is a way to keep them version controlled. Visual Studio has SQL Database Project option.
Yeah, Visual Studio has SQL Database Project is very much underappreciated gem... wel, you just gave me an idea ;)
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.