Re: Table normalization

Thanks Kenneth,

of course that there is no exact and general threshold for triggering the process of normalization (table decomposition). Also, I do not expect the foolproof recipe and I do know that many of the skills in database design are won by expirience.

At this moment I do not have big expirience with DB design but do not want to regret for newbie mistakes in future. So, I'd like to hear something usefull from other expirienced DB designers how they cope with such a issues (like normalization is) in their praxis.

--

Stjepan Brbot


<Kenneth Koenraadt> wrote in message
news:3d3e8493.12710967_at_news.capgemini.se...


>

> Hi Stjepan,

>

> There is no general "treshold", the question of normalizing  depends

> of what is possible and necessary.

>

> Putting "Street" in a separate table would be problematic in a number

> of ways :

>

> 1) Street names are not unique. Same street name appears in different

> towns.

>

> 2) Street names can be spelt differently.

>

> 3) New streets come up and old streets disappear frequently.

>

> 4) You will probably never get a full list of  all streets in the

> world or even in your country, unless you are the national Mail

> Company . Thus  your street reference table will never be up to date,

> so you will never really be able to use it for anything.

>

> So a "street" reference table will probably never be useful for you.

> On the other hand, a ZIP code reference table would be obvious to

> implement. There is a limited and well-defined set of ZIP codes, they

> are easy to achieve, and you would probably want to validate your

> customers ZIP codes.

>

> - Kenneth Koenraadt