Re: Agility and Data Design (was: Dreaming About Redesigning SQL)

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:lRqmb.23030$Fm2.10988_at_attbi_s04...
> "Mike Preece" <michael_at_preece.net> wrote in message
news:1b0b566c.0310232104.1acc58c4_at_posting.google.com...
> > "Marshall Spight" <mspight_at_dnai.com> wrote in message
news:<Mv%lb.5734$9E1.26853_at_attbi_s52>...
> > >
> > > Well, it sounds like what you're describing falls into the category of
> > > what I was describing as smaller homogeneous systems, where I
> > > said it "may work well enough."
> > >
> > Yes, maybe. What would your upper limits be for a "smaller homogeneous
> > system"? Maybe it would be best to use number of users, annual
> > turnover - that sort of thing - to measure by, as (and I'm really not
> > trying to provoke by saying this) the number of "transactions",
> > "records", "tables", "total database size", number of IT staff, total
> > IT expenditure and required hardware will all be smaller on an
> > equivalent Pick system.
>
> Fair enough. But that's hard to do; clearly, how much use
> a system gets is independent of how complicated or hard
> to develop it is. Metrics like "how many pages is the
> requirements doc" spring to mind, but then you have
> to control for the authors of those document, so that's
> quite difficult.
>
> Clearly, heterogeneity is easy enough to identify, though:
> if all the apps are written in the same language, then you've
> got a point of simplicity that makes your life easier.
>
> You've ruled out number of tables, but how about number
> of attributes? Would that be comparable?
>
> Also, I think number of developers is a reasonable metric,
> even if it is lower for Pick systems. The reason I care about
> this is if System A can only grow up to 10 developers but
> System B can grow up to 100, then there will be some jobs
> that can only be done in System B (given some specific
> time constraints,) even if System A is twice as efficient
> as System B with 5 developers.
>
> I dunno; a lot of these issues are measurable, but only
> at a cost of hundreds of thousands of dollars.

Try using business rules (ie. integrity constraints) as a metric. Received on Sat Oct 25 2003 - 15:04:43 CEST