Re: Stupidest table I ever saw

> You mean that table definition becomes more compact like this
>
> TYPE string_list_t AS TABLE OF VARCHAR2(240);
>
> table PRICING_ATTRIBUTES (
> PRICING_ATTRIBUTES string_list_t,
> PRICING_CONTEXT VARCHAR2(30),
> QUALIFIER_ATTRIBUTES string_list_t
> QUALIFIER_CONTEXT VARCHAR2(30)
> }
>
> right? Hey, this is not funny any more. People still would question if we could
> query such a table, and if the application program around it would be readable,
> but is not as strikingly stupid as the original.

> It is amaising how
> arrays/collections are able to hide design ridicule, though. Maybe this is why
> relationists dislike traditional programming fetures;-)
>

Indeed. Managers can often follow and see the structure of a RDBMS setup, but would rarely touch an array.

>
> In article <ZvWQ6.4556$rn5.235328_at_www.newsranger.com>, Vadim Tropashko says...
> >
> >That was clearly written before nested tables and other modern stuff arrived.
> >The question is if one would code this with nested table (aka array), would it
> >make the design less stupid?
> >

Are you saying that one cannot fix (normalize) the table? That is the first thing I would try to do. However, jillions of programs may reference it in its current (nasty) state.

Hey! I got a brilliant idea! Turn it into an OO class with 90 set/gets! Just kiddin'.

> >In article <tGXM6.6343$6j3.567845_at_www.newsranger.com>, Mikito Harakiri says...
> >>
> >>Name Null? Type
> >>------------------------------- -------- ----
> >>PRICING_ATTRIBUTE1 VARCHAR2(240)
> >>PRICING_ATTRIBUTE2 VARCHAR2(240)
> >>PRICING_ATTRIBUTE3 VARCHAR2(240)
> >>PRICING_ATTRIBUTE4 VARCHAR2(240)
> >>PRICING_ATTRIBUTE5 VARCHAR2(240)
> >>PRICING_ATTRIBUTE6 VARCHAR2(240)
> >>PRICING_ATTRIBUTE7 VARCHAR2(240)
> >>PRICING_ATTRIBUTE8 VARCHAR2(240)
> >>PRICING_ATTRIBUTE9 VARCHAR2(240)
> >>PRICING_ATTRIBUTE10 VARCHAR2(240)
> >> ... 90 more
> >

Isn't there also 90 "QUALIFIER_ATTRIBUTES" snipped out?

> >
>
>
>

-T- Received on Sun Jul 22 2001 - 01:26:42 CEST