Forgot your password?
typodupeerror
User Journal

Chacham's Journal: Verbiage: Tim Gorman rants on "DB independence" 8

Journal by Chacham

Tim Gorman ranted about Database independence (thanx to Hemant for the link). Nothing too special, but it's a good point that not everyone gets.

My favorite line is: It is clear that, upon retrospection, in-house applications *rarely* have a need to be "database independent", but rather that databases have a need to be "application independent".

A co-worker pointed out the final line as his: Question authority -- especially IT people who have embedded the word "architect" into their job title...

Oh, how true.

This discussion has been archived. No new comments can be posted.

Verbiage: Tim Gorman rants on "DB independence"

Comments Filter:
  • by Bill Dog (726542)

    Not to take away from the point of the blog post, with which I agree, but I also agree with the featured comment at the end:

    It depends what your school of thought is. But I believe the database should store raw data. It should guarantee contstraint and referential integrity. That's it. Any data manipulation/calculation/display should be in the application layer.

    I too subscribe to the db being an efficient data store, and this means letting it sort and filter records on queries like its optimized to do, but

    • When it's appropriate to use Stored Procedures:

      When a crapload of people / clients are going to use the exact same query over and over.
      Put it in a Stored Procedure so it can be optimized, and you also remove the processor intensive SQL parsing out of the equation. This leads to a massive performance gain.

      Other than Queries, and an occasional insert statement wrapped in a Stored Proc to simplify things, I agree.

      Consider this (PostgreSQL):
      CREATE TABLE foo (
      SomeString text,
      DMetaphoneCode text,
      D
    • The only good reason I've ever seen to use a trigger is logging - and that isn't always necessary anymore with some products as they've added built in stuff as part of their security.

      • for when db executes a command and gets updated data (external to organisation) which is then parsed and added to db. Data reflects current state of something and you want changes (above threshold X) notified to certain people, processes and or systems. Or is the type of logging you mean in a very general sense.

        • I mean logging in the security sense. Recording who does what in the database.

          Everything else I'd probably rather see in the application. Data coming from outside is going through an app -- let it do the work.

  • You end up stuck with the lowest common denominator, and before mysql development picked up, that was really damn low. Even now, there's a lot of stuff out there that's either non-standard or is standard but isn't supported in everything.

    You can have my PostgreSQL SELECT DISTINCT ON () when you pry it from my cold, dead hands.

  • by FroMan (111520)

    For someone who has 25 years of development experience, he must be amazingly lucky to have never gone through an acquisition or merger which required a new database platform. In my paltry few years compared to him I have seen at least two. Sometimes the corporate overlords don't care what your product runs on the back end, but other times they demand a database different from what your product currently runs.

    I agree with Bill Dog above on his view of triggers, and I would assume stored procedures also. I

    • by Chacham (981)

      I can understand having to implement a stored procedure for a true performance issue, but just because it is faster than executing on the client is not a good enough reason. Developer time costs a lot more than hardware, so your developers need to know everything that is happening as quickly as possible. Having to switch from Java, C, or whatever language the product is developed in to PLSQL or whatever other language is a cost of developer time.

      The cost is saved by having a standard library for DB operatio

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982

Working...