Dr Herbie said:
spivonious said:
*snip*

I have found there are generally two types of developers (with respect to databases):

  1. Developers who started writing applications and discovered databases were a useful place to store data. (I am this type).
  2. Database admins who discovered that they could code up a better UI for their database.

Type 1 developers tend not to see database as anything other than a data store and these are the devs who tend not to be interested in new SQL developments. They are also the majority of developers

Type 2 devs tend to want all the logic in stored procedures, while Type 1 want it all in code.

The other issue is that Type 1 developers tend not to be so good at SQL.  I can string a complex SQL statement together, but it's a struggle and they tend not to be performant.  SQL takes a different kind of thinking than OOP and I'm just not there yet.

We briefly had a Type 2 developer at our company (he mistakenly thought he was going to be included in redundancies and got another job before we told him we wanted to keep him), and he did things like rewriting an old stored proc that took 3min 45 seconds to a version that took 15 seconds.  Useful guys, Type 2s.

Smiley

Herbie

I agree, although I'd describe myself as "Type 1.5" Smiley

If it makes sense to put in a stored procedure (e.g. some common function that lots of programs are going to use), it's going in the database. If it's something specific to my app, then it's going in code.

Maybe it's because I took a database course in college that was all T-SQL.