Re: Import/Normalize approach - column-DML, or loop
On Sat, 31 Jan 2004 00:06:28 GMT, "David W. Fenton"
<dXXXfenton@bwa y.net.invalid> wrote:
[color=blue]
>Steve Jorgensen <nospam@nospam. nospam> wrote in
>news:75ll105g7 st0pdnoqhn1r3vp v664erila9@4ax. com:
>[color=green]
>> On Fri, 30 Jan 2004 19:39:25 GMT, "David W. Fenton"
>><dXXXfenton@b way.net.invalid > wrote:
>>
>> ...[color=darkred]
>>>> Yeah. If i get what you're saying, I don't thing ripping
>>>> arguments into 10 or 40 new columns will be a good thing, and
>>>> anything short of the 40 or so means writing more code to handle
>>>> the arguments past #10 or so differently than the rest.
>>>
>>>Well, I'm rather shocked at the idea that there'd be 40 separate
>>>values stored in a single field. I know you said it was a
>>>spreadshee t, but what kind of morons would write a spreadsheet
>>>that complex when they obviously need a database?[/color]
>>
>> It probably is stored in a database inside the proprietary system
>> it comes from. What I get is the spreadsheet exported from that
>> system. Also, the items in the export are very short codes.[/color]
>
>So, you're normalizing data that has been denormalized for export?
>
>How stupid is that?
>
>Wouldn't it be better to have someone skip the spreadsheet and have
>a normalized export process instead?[/color]
Of course, that was the first thing I asked the client after they gave me the
requirements. It's a totally closed system. Since it provides valuable
market data on a subscription basis, presumably, they think giving customers
too much access would compete with their own analysis consulting business - so
we end up working around them.
It's not the first time I've seen this sort of thing, and it probably won't be
the last.
On Sat, 31 Jan 2004 00:06:28 GMT, "David W. Fenton"
<dXXXfenton@bwa y.net.invalid> wrote:
[color=blue]
>Steve Jorgensen <nospam@nospam. nospam> wrote in
>news:75ll105g7 st0pdnoqhn1r3vp v664erila9@4ax. com:
>[color=green]
>> On Fri, 30 Jan 2004 19:39:25 GMT, "David W. Fenton"
>><dXXXfenton@b way.net.invalid > wrote:
>>
>> ...[color=darkred]
>>>> Yeah. If i get what you're saying, I don't thing ripping
>>>> arguments into 10 or 40 new columns will be a good thing, and
>>>> anything short of the 40 or so means writing more code to handle
>>>> the arguments past #10 or so differently than the rest.
>>>
>>>Well, I'm rather shocked at the idea that there'd be 40 separate
>>>values stored in a single field. I know you said it was a
>>>spreadshee t, but what kind of morons would write a spreadsheet
>>>that complex when they obviously need a database?[/color]
>>
>> It probably is stored in a database inside the proprietary system
>> it comes from. What I get is the spreadsheet exported from that
>> system. Also, the items in the export are very short codes.[/color]
>
>So, you're normalizing data that has been denormalized for export?
>
>How stupid is that?
>
>Wouldn't it be better to have someone skip the spreadsheet and have
>a normalized export process instead?[/color]
Of course, that was the first thing I asked the client after they gave me the
requirements. It's a totally closed system. Since it provides valuable
market data on a subscription basis, presumably, they think giving customers
too much access would compete with their own analysis consulting business - so
we end up working around them.
It's not the first time I've seen this sort of thing, and it probably won't be
the last.
Comment