Loading ...
Sorry, an error occurred while loading the content.

RE: [agileDatabases] Database refactoring

Expand Messages
  • Scott W. Ambler
    Assuming that the DB abstraction is appropriate, one of the advantages of it is that it reduces the coupling between your app(s) and the DB(s). This will make
    Message 1 of 15 , Apr 6, 2006
    • 0 Attachment
      Assuming that the DB abstraction is appropriate, one of the
      advantages of it is that it reduces the coupling between your app(s)
      and the DB(s). This will make refactoring easier.

      - Scott

      At 10:06 AM 4/5/2006, you wrote:
      >I'm not discounting the act of DB Refactoring. I was skeptical of
      >the ORIGINAL author's post that talked about adding another DB
      >abstraction layer to aid the refactoring. My view was that I wasn't
      >fond of adding yet another abstraction layer to an architecture to
      >make changes. My view is that, 9 times out of 10, you are making
      >functional changes to an application (and I include performance
      >upgrades in functional changes) and should just take the time to
      >make those changes throughout, rather than spend time building an
      >over complicated abstraction.
      >
      >Someone else pointed out to the author that there were tools to help
      >make those changes throughout the applicaiton (via code generation I
      >believe) and the matter was settled.
      >
      >D
      >
      >
      >----------
      >From: agileDatabases@yahoogroups.com
      >[mailto:agileDatabases@yahoogroups.com] On Behalf Of Scott W. Ambler
      >Sent: Wednesday, April 05, 2006 8:44 AM
      >To: agileDatabases@yahoogroups.com
      >Subject: [agileDatabases] Database refactoring
      >
      >At 09:08 AM 3/29/2006, Chris wrote:
      > >--- In agileDatabases@yahoogroups.com, "Dave Sanders" <vulgrin@...> wrote:
      > >
      > > > Call me old fashioned, but I'm of the mind that if I'm going to change
      > > > the database on an established application, that I'm going to be
      > > > making enough of a change where functionality is changing. I.e., I'm
      > > > not going to just go in there and change a field name - I'm going to
      > > > add a whole new table, new relationships, etc. This is going to
      > > > neccessitate code changes ANYWAY, as I'm adding new functionality to
      > > > the application.
      > >
      > >You're old fashioned! ;-)
      > >
      > >Seriously though, it sounds like you are suggesting that Refactoring
      > >Databases is a bad idea. I suspect Scott may have something to say on
      > >the matter, since he recently published a book with that title!
      >
      >Wow, almost missed this one.
      >
      >Yes, I think that you should consider database refactoring
      >seriously. The entire point is that just like with code refactoring,
      >it's much safer to make small changes than it is to make large
      >changes. The book itself,
      >www.ambysoft.com/books/refactoringDatabases.html , describes in
      >detail how to do exactly this.
      >
      >- Scott

      ====================================================
      Scott W. Ambler :-)
      Senior Consultant, Ambysoft Inc.
      www.ambysoft.com/scottAmbler.html

      Refactoring Databases: Evolutionary Database Design
      (www.ambysoft.com/books/refactoringDatabases.html) is now available!
    • bobalicious1974
      ... I think your statement that you include performance upgrades in functional changes is quite enlightening. I implement the following 5 (yep FIVE) layers in
      Message 2 of 15 , Apr 6, 2006
      • 0 Attachment
        At 10:06 AM 4/5/2006, you wrote:
        >I'm not discounting the act of DB Refactoring. I was skeptical of
        >the ORIGINAL author's post that talked about adding another DB
        >abstraction layer to aid the refactoring. My view was that I wasn't
        >fond of adding yet another abstraction layer to an architecture to
        >make changes. My view is that, 9 times out of 10, you are making
        >functional changes to an application (and I include performance
        >upgrades in functional changes) and should just take the time to
        >make those changes throughout, rather than spend time building an
        >over complicated abstraction.

        I think your statement that you include performance upgrades in
        functional changes is quite enlightening.

        I implement the following 5 (yep FIVE) layers in all my PHP and Oracle
        applications. It includes 2 layers that exist purely for database
        abstraction.

        Physical Database structure (Tables / Views / etc)
        PL/SQL Access Layer (Packages - the only things that access the tables)
        PHP Server objects (The only PHP code that access the database -
        contains NO SQL)
        PHP Business Objects
        PHP / HTML / Javascript UI Layer

        The PL/SQL Access Layer and PHP Server objects are effectively the
        database abstraction layer, and combined they allow the database
        structure to be performance tuned without the need to affect the
        business object layer and above. In fact, it allows for the table
        structures and SQL statements to be tuned without any change to the
        PHP layer whatsoever. In many cases we've implemented caching
        mechanisms in the PL/SQL layer and then others in the PHP server
        object layer. Both are dumb of each other.

        Anyway, the abstraction layers mean that we can freely alter the
        underlying database structure. Refactoring for clarity... normalising
        for purity or denormalising for performance... as long as the logical
        meaning doesn't change the PHP codebase doesn't need to.

        Personally, I see neither refactoring or performance tuning as
        functional changes. Refactoring is by definition a change that does
        not introduce a change in functionality.
        Performance tuning should only change the performance characteristics
        of the application, not the functionality.

        Yep, most of the time, when we develop in the database it propogates
        through the system. But that's partly because it's so easy to
        refactor the DB and tune the apps we build that we don't spend a lot
        of doing either ;-)
      • Curt Sampson
        ... I ve got to say, I ve seen a lot of attempts at this, and they almost invariably go way too far on the side of too much abstraction. People seem to find it
        Message 3 of 15 , Apr 7, 2006
        • 0 Attachment
          On Thu, 6 Apr 2006, Scott W. Ambler wrote:

          > Assuming that the DB abstraction is appropriate, one of the
          > advantages of it is that it reduces the coupling between your app(s)
          > and the DB(s). This will make refactoring easier.

          I've got to say, I've seen a lot of attempts at this, and they almost
          invariably go way too far on the side of too much abstraction. People
          seem to find it a lot easier to add unnecessary abstration than stick to
          YAGNI.

          cjs
          --
          Curt Sampson <cjs@...> +81 90 7737 2974
          The power of accurate observation is commonly called cynicism
          by those who have not got it. --George Bernard Shaw
        Your message has been successfully submitted and would be delivered to recipients shortly.