> when using IDEs with the SQL vendors plugins Do these plugins mean you don't get to store them in git? You're just going to open up the developer studio and

> when using IDEs with the SQL vendors plugins Do these plugins mean you don't get to store them in git? You're just going to open up the developer studio and YOLO a change to the stored procedure, live in production? Because the whole argument is that the way we do version control, code review, bisecting, single-artifact deployment, etc is generally at odds with how stored procedures work. Saying "but my IDE has a good plugin" solves maybe 1/100th of the problem. Some answers to doing stored procedures in a version control system that I've seen: - Put everything in a migrations directory, and every time you change the stored procedure, introduce a new migration that completely rewrites it. (Merge conflicts are hell with this, plus all the massive amount of waste it generates in the checked-out tree) - Put the stored procedures in a directory as normal code and then "sync" them to the database at runtime (with all the massive foot-guns this entails, trying to detect if they've changed versus what's in the database, etc) - Eschewing stored procedures in favor of using prepared statements and having your ORM figure out when to use them There may be others but I think they're all going to look like some form of one of the above.