Re: Is this bad design ?

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:404f9ee3$0$558$e4fe514c_at_news.xs4all.nl...
> Dawn M. Wolthuis wrote:
>
> > ...
> > I'm thinking in terms of the thick of a bell curve -- not those that are
> > huge enough to end up in one tail or so small they are in the other.
>
> So yes, computerized and no, not normalized? (checking wether I get your
> point)

How you do normalization depends on the model you work with, but yes, I am talking about a system that is designed and not just coded from napkin specs.

<snip>
> > Yes, yes! We want to project well enough in advance to minimize major
> > changes, but then ensure we have an implementation that can we can
handily
> > refactor as needed. In the relational model just having an attribute of
an
> > entity that switches to cardinality > 1 requires a refactoring to put
that
> > attribute in a separate table. The overall costs (including risks) of
all
> > refactorings required over the life of a system that is relevant.
>
> http://www.hyperdictionary.com/computing/refactoring :
> > Definition:
> >
> > Improving a computer program by reorganising its internal structure
> > without altering its external behaviour.
>
> At first I had problems trying to understand what you
> meant with refactoring in this context,
> so I looked it up. I think you are talking about changing the
> internal structure as a consequence of a change in the desired
> external behaviour (a.k.a. the requirements). Refactoring
> is just the opposite of that - even though the goal of refactoring
> indeed is to get a piece of software that is easier to maintain (adapt
> to changing requirements). One way of doing that (refactoring)
> is to eliminate unwanted redundacy.

I was using the term "refactoring" related to the data structures. You refactor your database, for example, if you have modeled your data in 1NF and requirements change so that an attribute now requires 2 values instead of 0-1. The user should only see the new requirement come to life, while, in fact, a new table was created with an attribute moving to it. A way of implementing the new requirement without refactoring would be to add a second_value_of_attribute field to your original table.

> So I guess at some point in the bell curve
> you mentioned one has to normalize the data, halting all exteral
> changes until it's done. Major business risks. I am not
> saying that normalized is always better, but I do think it is
> necessary in order to manage growing complexity at some point.

I'm in complete agreement that we want to plan for maintenance and that since we cannot plan for all possibilities, we need to ensure we have the flexibility in our tools and design to make changes accurately and quickly.

> Now with hindsight one could say: Why not structure
> your data right in the first place? I have also seen people
> *over* structuring data for all kinds of scenarios
> for future development. This lead to a lot of YAGNI code,
> and the changes that *did* occur
> were not (ok some of them were) anticipated.

I think a lot of relational design relates to YAGNI while some of the more obvious desired changes end up getting hard-coded into the database -- for example, cardinality of attributes. Simply by having a non-candidate key attribute in a table makes that attribute a candidate for needing to have more than one such value in the future, often requiring significant changes to applications in spite of the use of logical views.

--dawn Received on Thu Mar 11 2004 - 00:25:02 CET