I mostly agree. It's a matter of degree. There is a role for well placed stored procedures/triggers in the world... not a big place... but a place. I maintain it isn't because application programmers can't learn relational thinking or to optimize their SQL. I spent years as the performance whipping boy for my company and swam through lakes of bad SQL. Didn't make me want this gunk in pl/sql. Just made me want pound a proper equijoin construction into some skulls. Believe it or not, I'm something of an evangelist for the power of relational operations in a row-by-row thinking company. I've just seen the kind of goo-balls that apps coded in the DB become.
No. I disagree. You ask the *application* to process the order. The application logic knows what the rules are and is the only component entitled to change the database.
If you have other processes connecting straight to the database and changing data directly, you have serious issues. Maybe barricading yourself in FortressDB is the right approach for you if you live among marauding barbarians pillaging your relational store at every turn. This is not, however, a world you should accept without stiff resistance.
No. He got it right the first time. Why on earth would you want your RDBMS vendor cramming their lousy procedural programming language down your throat? For the privilege of burning cycles for your application code on CPUs that you've paid your database vendor upwards of $10k per core for licenses? Or is it because your control-freak DBAs like the app code right up close to the data where they can micro-manage it. The only folks with a worse appreciation of programming languages and application design than sysadms are DBAs.
Finally, if you want to scale, getting your app code out of the DB is the best first step. Outside the database server you can throw cheap app servers at a problem if you need to. Growing your DB server is another beast altogether. Despite the IBM/Oracle propaganda, big grown-up businesses are very hesitant to cluster their databases. Not just the cost but for tuning and safety (the odds of bugs in this super-complex technology bringing them down). In general, you have one live DB server for an app and at least one failover. Growing that single DB server is a lot harder than throwing in a few more pizza boxes, or whatever.
Slashdot Mirror
I mostly agree. It's a matter of degree. There is a role for well placed stored procedures/triggers in the world... not a big place... but a place. I maintain it isn't because application programmers can't learn relational thinking or to optimize their SQL. I spent years as the performance whipping boy for my company and swam through lakes of bad SQL. Didn't make me want this gunk in pl/sql. Just made me want pound a proper equijoin construction into some skulls. Believe it or not, I'm something of an evangelist for the power of relational operations in a row-by-row thinking company. I've just seen the kind of goo-balls that apps coded in the DB become.
If you have other processes connecting straight to the database and changing data directly, you have serious issues. Maybe barricading yourself in FortressDB is the right approach for you if you live among marauding barbarians pillaging your relational store at every turn. This is not, however, a world you should accept without stiff resistance.
Finally, if you want to scale, getting your app code out of the DB is the best first step. Outside the database server you can throw cheap app servers at a problem if you need to. Growing your DB server is another beast altogether. Despite the IBM/Oracle propaganda, big grown-up businesses are very hesitant to cluster their databases. Not just the cost but for tuning and safety (the odds of bugs in this super-complex technology bringing them down). In general, you have one live DB server for an app and at least one failover. Growing that single DB server is a lot harder than throwing in a few more pizza boxes, or whatever.