RE: New SQL Datatype RECURRINGCHAR

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