Re: Stupidest table I ever saw

From: Mikito Harakiri <nospam_at_newsranger.com>
Date: Sat, 21 Jul 2001 23:26:39 GMT
Message-ID: <oaXQ6.4593$rn5.237328_at_www.newsranger.com>


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;-)

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?
>
>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
>
>
Received on Sun Jul 22 2001 - 01:26:39 CEST

Original text of this message