Not even 1NF.
J.
I think I would enjoy querying that table. Eg. select all records that have
at least one pricing_attribute not null. Would be fun.
Goran
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.2...@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.5...@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
>
>
Need marsalling-unmarshalling programmer for Pricing Attributes.
Knowledge of modern technologies desirable, but not requred. Ideal candidate
must have significant experience calling functions with 200 arguments or more.
In article <tGXM6.6343$6j3.5...@www.newsranger.com>, Mikito Harakiri says...
>
> 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.2...@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.5...@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-
Aliens?
-T-
> This message is at least a month old. Why is it popping
> back up now?
>
One possibility is an attack of Magistrate virus against an Outlook client. The result
is a message to everyone in the user's address book (including USENET groups) with a
segment of an earlier message or saved text as the message.
================================================================
Mike Mohr, Systems Administrator === Email: Mike...@aut.ac.nz
Information Technology Group === Phone: 64 9 917-9999 x8133
Auckland University of Technology === Fax: 64 9 917-9901
PO Box 92006, Auckland, New Zealand =
http://home.aut.ac.nz/staff/mmohr/
================================================================
Chaos reigns within. Repent, reflect, reboot. Order shall return.
"Mikito Harakiri" <nos...@newsranger.com> wrote in message
news:tGXM6.6343$6j3.5...@www.newsranger.com...