Re: [agileDatabases] Re: Developer DB Instances
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.
- Todd Carrico wrote:
>In the astronomy community, nobody agrees on anything. Somebody with
> Interesting... from the MS side of things, I would have said that .Net
> was king, and Java was dead... Different worlds I suppose..
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.