Moritz Klein wrote:
> tunity5_at_yahoo.com wrote:
>
>>I would be interested in learning more about the kind of
>>domain/database design that requires 1000 columns in a table. I am
>>just curious as to the application that needs to support this. Just
>>imagine different applications/modules for update/delete/insert of a
>>few columns each! Or even, from a human factors perspective, how
>>would developer(s) deal with 1000 columns, remember them individually
>>or their relationships to each other?
>
>
> My background:
> I am currently working at a chair for statistics and mathematics of the
> University of Mainz.
> We do researchs on economical status related to human behaviour and
> expectations.
>
> This is what I have to do:
> There are 10 Waves of a panel study, each wave consists of four tables
> (provided in tab-delimited ASCII), befor being able to insert the data I
> have to process the whole thing because of tab-delimited and missing values
> only being a blank. This for I wrote some perl script to process the rows
> and make "\t \t" change to "; ;". The first row of every file is a header, I
> use this to generate my create table statements. Within the processing I
> generate create-scripts, control-files and a batch-file to trigger
> data-import with the use og SQL*Loader. I was told not to change the design
> of the tables. That's why I said modell cannot be changed. But I think the
> design needs a change as Sybrand already stated. I had to deal with large
> national surveys befor but never ran into this problem. Missing data and
> changing value-names between different years mainly produced the headache
> until now.
>
>
>>Could you please elaborate on the type of the application? While you
>>noted that the design is not to be changed, there may be other ways to
>>manage this in the future or in other projects.
>
>
> As stated above the design comes with the data, provided by some 3rd party.
> Type of application will be the aggregation of economical data to find
> reasons that control human behaviour and expectations. We will make
> extensive use of PL/SQL-Functions for decoding numbers to human readable,
> views for aggregating where its easy as well as PL/SQL-Functions that
> agregate the data and provide for example economical status for a benefit
> unit.
>
> Wow, that took a while. I tried to be as clear as possible but it's nearly
> 1:00 so maybe I did not achieve this completely. Hope you got an overview of
> application and purpose.
>
> Cheers
> Moritz
You need to think vertically not horizontally.
Rather than thinking:
id, col1, col2, col3, col4, col5, col6, ...
1 Y N Y Y Y N
think:
id, col_number, col_value
1 1 Y
1 2 N
1 3 Y
1 4 Y
1 5 Y
1 6 N
No matter what the data looks like ... load it relationally.
Daniel Morgan
Received on Tue Jul 20 2004 - 00:31:27 CDT
