From OpenSQLCamp

Contents 1 Goal: where to draw the line between code and DB 1.1 Stored Proc 1.2 So... where do you draw the line? 1.3 What are some red flags to watch for 1.4 Advantages of distinct layers and proper API's between them 1.5 But what about parallelization?

Goal: where to draw the line between code and DB

Stored Proc

Can be used as a sane middle step where you start to blur the line of logic and store, though it comes with the trade-off that it is something that needs to be maintained and is not feature complete across all DB's

So... where do you draw the line?

• what are the goals for your project?
  • If you are storage reliant then you will likely want to lean in favor of more DB centric.
  • If you are more calculation and assembly of data then you might lean more towards code.
• in the end really it is dependant on the make up of your team, what they are handy with, and what the goals of your project really are.

What are some red flags to watch for

• what are you really gaining from the specific features that your language/db offer?
  • long term getting locked in to a specific feature then you are locked in to that platform.
  • is specialization really worth it, you might know what and why you are using this but will your replacement in 5 years?
  • in most cases you will likely be better off working a more generic solution.

Advantages of distinct layers and proper API's between them

In a 'simple' web app you have a:

• web server
• programing language
• data store

By keeping these layers distinct then you can pull them out and migrate out parts. This becomes a problem when you start to blur these layers, for example if you have an app that leans heavily on mod_perl then you now are tied to apache, its the same if you start to shove a bunch of logic in to the DB because you are now tied to that DB.

But what about parallelization?

If you can create a schema that is insert only then you can (more) easily start to parallelize your data store.