Re: Is this bad design ?
From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Thu, 11 Mar 2004 01:15:24 +0100
Message-ID: <404fafab$0$558$e4fe514c_at_news.xs4all.nl>
>
>
> 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.
Date: Thu, 11 Mar 2004 01:15:24 +0100
Message-ID: <404fafab$0$558$e4fe514c_at_news.xs4all.nl>
Dawn M. Wolthuis wrote:
[snip refactoring - I think that's clear now, thank you]
> ...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.
Sometimes a ponton-bridge (meant to last for weeks or days) lasts for years, even gets maintened. When the traffic doesn't get too heavy, that's ok. I wouldn't like it as a key component in the infrastructure. Received on Thu Mar 11 2004 - 01:15:24 CET