From: "Daniel A. Morgan" <dmorgan@exesolutions.com>
Newsgroups: comp.databases.oracle.misc
Subject: Re: Managing tables with >800 fields
Date: Tue, 05 Jun 2001 23:07:26 -0700
Organization: EXE
Message-ID: <3B1DC89E.4D4A9825@exesolutions.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <6d8d2ec4.0106050514.62eb8bdd@posting.google.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cache-Post-Path: yabetcha.drizzle.com!unknown@ava25.drizzle.com
X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/)
X-Complaints-To: newsabuse@supernews.com
Lines: 31


Tom Lewis wrote:

> I have an operational data store with 10 million records in an account
> table and 500 million records in a transactional table. The account
> table is >800 fields wide but only c30 of these are frequenetly used.
>
> Is it worthwhile to split the 800 field table into one of 35 fields
> and one of 765 fields and if so, what is the most effective way to
> join they back together?
>
> Tom

I can, without fear of contradiction, say that there is no normalized
table on this planet with 800 fields. That is just a literal
impossibility.

Learn how to normalize a database and make that your first priority. What
you have here is a nightmare.

Split into two tables? Absolutely not. I'd be thinking in terms of
splitting into a minimum of 100 tables to even come close to normalizing
the data unless your fields names are stuff like ADDRESS1, ADDRESS2,
ADDRESS3, ADDRESS# ....

If that is the case you need to learn to think vertically ... not
horizontally. So you end up with a three field table such as ADDRESSNUM
(values 1, 2, 3, 4, etc.) and ADDRESS_VALUE (the actual address), and a
primary key.

Daniel A. Morgan