Subject | Re: [firebird-support] avoiding duplicates |
---|---|
Author | Jason Dodson |
Post date | 2005-07-12T13:00:25Z |
I agree, what I originally posted didn't work, and I gave a warning of
the repercussions... but I have since made a working example, and it
seems to work peachy. In a case like this where the original poster used
a table named "Company", you will eventually approach the limit of
companies you will be dealing with. While storing would take some time
and resources, I was under the impression it wouldn't be done often.
Anyway, the very term "Normalization" means "the process of removing
redundant data from your tables in order to improve storage efficiency,
data integrity and scalability". Having an UPPERized field is redundant
data. It has no extra value other then it saves you from doing work in
your application.
Just my thoughts.
Jason
the repercussions... but I have since made a working example, and it
seems to work peachy. In a case like this where the original poster used
a table named "Company", you will eventually approach the limit of
companies you will be dealing with. While storing would take some time
and resources, I was under the impression it wouldn't be done often.
Anyway, the very term "Normalization" means "the process of removing
redundant data from your tables in order to improve storage efficiency,
data integrity and scalability". Having an UPPERized field is redundant
data. It has no extra value other then it saves you from doing work in
your application.
Just my thoughts.
Jason
>
> Being (in addition to sloppy with syntax) something of a pedant, I'd
> like to know which rule of normalization is violated by adding an upper
> field to the table.
>
> Cheers,
>
> Ann
>