3 ms·

I disagree with this article. SQL is an decent (though crusty) language when used specifically for the purposes of interacting with relational databases. The fa

I disagree with this article. SQL is an decent (though crusty) language when used specifically for the purposes of interacting with relational databases. The fact that most database vendors have hacked mutually incompatible proprietary extensions on-top of it for doing other tasks doesn't make it a good choice for them. Why would you use SQL over a language that has been specifically designed for code reuse, integration and interacting with multiple systems (rather than just the database)? > Myth #1: Stored procedures can't be version controlled Of course they can, but unlike normal code which runs/builds directly from the file-system, a sproc tends to be written directly on the database server (since you won't get all those fancy refactoring/debugging tools unless you do so). Copying it to the fs before committing your changes is a step that people often forget, or one that requires yet more tools. > Myth #2: Managing the impact of changes in the database is hard > Myth #3: Database tools lack modern IDE features His examples of basic refactoring tools hardly compares to something like ReSharper. > Myth #5: Code in the database can’t be properly encapsulated and reused, you need an object-oriented language for that They can be encapsulated, but it's a pain. Even just getting data from one stored procedure to another can involve hackery like opening a connection to the database from inside the calling procedure. See this link: http://www.sommarskog.se/share_data.html http://www.sommarskog.se/share_data.html - none of these will work in even close to all situations.

tewolde 15y ago
I completely agree, technology is a lot like time & money. Throw enough of it at any problem and you'll likely solve it. When dealing with scale problems, the biggest asset is flexibility as you will likely need more than one kind of "database" and your logic layer will be the glue that holds it all together. Stored procedures are simply too focused a tool and often tied to a particular database to offer any comprehensive solutions.
jasonkester 15y ago
a sproc tends to be written directly on the database server ... Copying it to the fs before committing your changes is a step that people often forget No they don't. At least not more than once. Changing something on your dev database and forgetting to save your change scripts and check them in is analogous to changing html directly on the production web server and forgetting to save it locally and check it in to source control. It's a very bad idea, and nobody would ever actually do that. But if you did do it, your changes would evaporate during the next deploy, and after a few minutes of venting to the sky you'd learn to never ever do that again.
- cameronh90 15y ago
  Except my IDE doesn't require me to be editing while connected to the server to get all the useful refactoring/etc. tools. It only requires being attached to debug. Admittedly in most SQL editors, you can open up the file, then connect the IDE to the database. But it's hardly seamless (particularly if you have multiple databases), and certainly isn't like normal development where the filesystem is exactly what's running, and is the only user visible copy. The tools just all feel extremely immature compared to any IDE I've used. And to clarify, I'm talking about the dev SQL server, not developing in production.
  - jasonkester 15y ago
    Right, but we're not talking about IDEs. We're talking about SQL. No matter what you use to modify your database, be it a modeling tool, the table editor that comes with the database, a fancy VS.NET plugin, or a mysql command prompt, you're still producing SQL change scripts. Those change scripts always need to get saved out to a file and checked into source control. This is especially true if you're developing on a local database with multiple stages between you and production. You need scripts for everything so that your build can push things out to the next environment down the chain and eventually live. If you're not doing that, I can't imagine the pain you're introducing for yourself.

tewolde 15y ago

I completely agree, technology is a lot like time & money. Throw enough of it at any problem and you'll likely solve it. When dealing with scale problems, the biggest asset is flexibility as you will likely need more than one kind of "database" and your logic layer will be the glue that holds it all together. Stored procedures are simply too focused a tool and often tied to a particular database to offer any comprehensive solutions.

jasonkester 15y ago

a sproc tends to be written directly on the database server ... Copying it to the fs before committing your changes is a step that people often forget No they don't. At least not more than once. Changing something on your dev database and forgetting to save your change scripts and check them in is analogous to changing html directly on the production web server and forgetting to save it locally and check it in to source control. It's a very bad idea, and nobody would ever actually do that. But if you did do it, your changes would evaporate during the next deploy, and after a few minutes of venting to the sky you'd learn to never ever do that again.

cameronh90 15y ago
Except my IDE doesn't require me to be editing while connected to the server to get all the useful refactoring/etc. tools. It only requires being attached to debug. Admittedly in most SQL editors, you can open up the file, then connect the IDE to the database. But it's hardly seamless (particularly if you have multiple databases), and certainly isn't like normal development where the filesystem is exactly what's running, and is the only user visible copy. The tools just all feel extremely immature compared to any IDE I've used. And to clarify, I'm talking about the dev SQL server, not developing in production.
- jasonkester 15y ago
  Right, but we're not talking about IDEs. We're talking about SQL. No matter what you use to modify your database, be it a modeling tool, the table editor that comes with the database, a fancy VS.NET plugin, or a mysql command prompt, you're still producing SQL change scripts. Those change scripts always need to get saved out to a file and checked into source control. This is especially true if you're developing on a local database with multiple stages between you and production. You need scripts for everything so that your build can push things out to the next environment down the chain and eventually live. If you're not doing that, I can't imagine the pain you're introducing for yourself.