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

Re: [agileDatabases] Re: Developer DB Instances

Expand Messages
  • Cameron Laird
    On Tue, Mar 06, 2007 at 04:34:00AM -0000, bretweinraub wrote: . . . ... . . . I suspect we re talking past each other. I certainly agree that sequence--or
    Message 1 of 40 , Mar 6, 2007
    • 0 Attachment
      On Tue, Mar 06, 2007 at 04:34:00AM -0000, bretweinraub wrote:
      .
      .
      .
      > I mean changes to database objects (other than compiled code), as
      > tables or indexes, need to be applied in order, or you won't get a
      > consistent result. For example, if you have a script that alters a
      > column's data type, you had better have applied the script that
      > created the column in the first place or you'll get an error. If you
      > get in the habit of making your schema changes in haphazard order ...
      > you will get inconsistent results.
      >
      > I recall an SEI study on defects in production systems ... they listed
      > "variance in procedure" as the number one culprit. So to keep all the
      > little DB sandboxes at a constant revision, certain changes need to
      > be applied in a consistent order (like schema changes) so that all the
      > little dbs are exactly identical.
      >
      > Not all change management problems require "sequencing" of changes, of
      > course. Your email referenced "source" and "persisted data". Change
      > management for source is pretty well understood - aka sync build and
      > deploy. Application data can get complex, esp. in a production system
      > where this data can be "live". Its hard to give a cookbook recipe
      > for application data; "use case" analysis including deployment
      > scenarios probably work better for this stuff. There some art to it,
      > in my opinion.
      .
      .
      .
      I suspect we're talking past each other.

      I certainly agree that sequence--or "state awareness", as I
      first think to abstract it--is important in management of
      databases. I CERTAINLY agree that the data culture has made
      on me the impression that it's rather primitive in under-
      standing such matters as "variance in procedure". I, too,
      have experiences like the ones you describe from the last
      millenium where you eliminated several busy-work DBA jobs
      (although none of the vandalism to my vehicles ever had to
      do with IT, as far as I know). I think you're saying that
      application data is infeasible to "diff", and I agree with
      that. Also, use cases are important.

      The part I don't get is to regard this as unique to data
      management. What I see is that there's immense scope for
      improvement in configuration management on the data side;
      maybe you're just farther along that path than I, and see
      the problems that are still hidden to me.

      Another part is that I have absolutely no inclination "to
      keep all the little DB sandboxes at a constant revision"
      or make "all the little dbs ... exactly identical." I
      expect my developers' sandboxes to be minimal--just enough
      to allow 'em to develop productively. Maybe I don't under-
      stand what "identical" means here; if they're images,
      there's surely no problem. If you're saying that they're
      each achieved through a complex sequence of operations,
      but each is modified to match the focus of the sandbox
      owner, then I don't see the point of labeling "identical".

      'Sure feels to me as though there's a vocabulary skew afoot.
    • Donald McLean
      ... In the astronomy community, nobody agrees on anything. Somebody with money picks a platform/language that they like and implements a solution. If enough
      Message 40 of 40 , Mar 15, 2007
      • 0 Attachment
        Todd Carrico wrote:
        >
        >
        > Interesting... from the MS side of things, I would have said that .Net
        > was king, and Java was dead... Different worlds I suppose..

        In the astronomy community, nobody agrees on anything. Somebody with
        money picks a platform/language that they like and implements a
        solution. If enough people find the solution useful then eventually it
        becomes a de-facto standard (at least for a while). The result is that
        solutions run the gamut of platforms and languages.

        The only firm statistics that I have seen were a virtual dead heat
        between Macs and Linux with Windows a remote distant third.

        Now the system that I work on is a Java web application. The new version
        of the software has greater data-management needs than previous versions
        and so we adopted Derby + Hibernate. So far it seems to work just fine,
        but then we have just started with full-up system testing and haven't
        run any load tests yet.

        Using Hibernate isn't quite so obvious as the Hibernate fanatics seem to
        believe. I think that their documentation is difficult to navigate and
        important details are hidden away in tiny little remote corners. My
        inner cynic tells me that this could be a strategy for creating a market
        for Hibernate how-to books.

        Donald McLean
      Your message has been successfully submitted and would be delivered to recipients shortly.