On Tue, 3 Jul 2001, David Bennett wrote:
> The idea is to simplify the process of storing and accessing the data.
> Joins required a deeper knowledge of the relational structure. This
> also complicates application programming, two tables must be
> maintained instead of just one.
Sometimes, to maintain correctness, its necessary to have complex designs.
"All problems have simple, easy-to-understand, incorrect solutions".
> Again the idea is to simplify. Reduce the number of tables required to
> represent a business model.
Why? You should normalize your data, which _increases_ number of tables.
> >> - Eliminates use of joins and extended knowledge of data relationships
> >> for adhoc users.
>
> > For adhoc users, you can create a view so they won't be aware of joins.
>
> Now we have a master table, a lookup table AND a view?
> even more complication....
Well, that's called software development. If you don't want complications,
you can use MS-Access *:)
>
> >> It is often an advantage to actually store an entire word representing a
> >> business meaning as the value of a column (as opposed to a reference
> >> number or mnemonic abbreviation ). This helps to make the system
> >> 'self documenting' and adds value to users who are performing adhoc
> >> queries on the database.
>
> > No, that is against good database design and any database normalization.
>
> I would like to hear your argument on this. I don't see how optimizing
> the storage of reference value breaks a normalization rule.
What if tomorrow you will need to change text name for "OPEN" status to
"OPEN_PENDING_SOMETHING"? With your design, you will need to update all
rows in the table changing it. With normalized design, you just update the
lookup table. Etc, etc.
-alex