Re: Any new thoughts on OTLT (One True Lookup Table)

> solution has been commited to a single design. Is this a fair rendering
of
> what you are saying?

No I do not think your words represented my words.

I'll try again with the same example :
The goal is to build an application and a database
to run a (web-)shop. The shop is going to sell
electronic gagets.
The database should hold the 'typical' product
information.

At designtime and build time, you can do an in depth
analysis of the subject matter, but at design time it
is not know which gadgets will be available next year,
and which attributes and codes the gadgets will have.
But the database has to be able to search for gadgets
with certain attributes (and codes).
So at design time the 'problem' is completely clear,
but the 'gadgets' to be hold in the database have
not been seen on the market yet.

Next year an electronic compact disc folder (ecdf) will be
released, it's code class will be : 'red', 'green' or
'dark bleu', this describes the way the folding is
happening. Also there is a folding ratio the compact
disc folder will typically reach. And offcourse there
is size and weight. The size of the scrubber is another
aspect of the ecdf.
The search for an ecdf which can do both 'red' and 'green'
and has a scrubber of value 'blabla' and a ration of at least
2.6, must be possible.
The year after there are ecdf's with an color display,
for this display the sizes have to be mentioned but
also the 'gla-factor'. The 'gla-factor' is coded again.
(It's april fools day, so do not go looking for the gadget
in the shops (yet).)
The database can not be designed to hold the codes
needed for the ecdf in a modelled way. So we have
to revert to a 'generic' way of holding the codes.

"Laconic2" <laconic2_at_comcast.net> wrote in message
news:5oCdnUiOMc4spffd4p2dnA_at_comcast.com...
> "ben brugman" <ben_at_niethier.nl> wrote in message
> news:4067f586$0$6566$4d4ebb8e_at_read.news.nl.uu.net...
> >
> > And there are loads of databases designed to hold information
> > and codes, where the codes and the codetypes where not
> > available on design time. For example a shop (often a webshop)
> > runs on a database with an application where the database and
> > application (and the programmers behind it) where at design time
> > not familiar with the product, their attributes and the codes.
> > Specifically because at design time it was stated that the shop's
> > database must be able to hold information about products which
> > did not exist at design time.
>
> I don't want to twist your words. It sounds like you're saying that often
> design and implementation must charge ahead without waiting for an in
depth
> analysis, that the subject matter is still poorly understood by the time
the
> solution has been commited to a single design. Is this a fair rendering
of
> what you are saying?
>
> What kind of methodology to you use to acheive such agility?
>
> The reason I ask is because I've seen a large number of projects that
> started out this way, only to end up as death marches.
>
>
>
>
Received on Thu Apr 01 2004 - 09:55:54 CEST