Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: 23,000 Tables?

Re: 23,000 Tables?

From: cd2448 <cdyde_at_yahoo.com>
Date: 8 Nov 2006 16:20:06 -0800
Message-ID: <1163031606.106167.316460@h48g2000cwc.googlegroups.com>

Mark D Powell wrote:
> [snip].
>
> While 23,000 tables is a large number the fact whether this is good or
> bad depends on how it was determined that 23K tables should exist. The
> SAP product has more tables than what you list.
>
> If the tables represent unique entities and nor just copies of the same
> entity dedicated to a specific part of the business such as having a
> part_master table for each plant instead of just having one part_master
> table with a plant column so that one part_master can handle any number
> of plants.
>
> Also there is no point in picking up your current application and
> creating a table for every file that exists and just convering the
> existing code to programs that run on the new platform. You are
> spending a lot of money just to port your current set of problems
> rather than develop a new system to meet your business needs going
> forward. In other words these 23k tables should represent the business
> data in a fully relational design done from scratch. Otherwise it
> would probably be cheaper to stay on the current system.
>
> We have several table with more than 100 columns so 50 isn't that manny
> so long as each column is truely an attribute of the entity that the
> table represents.
>
> HTH -- Mark D Powell CPIM, CIRM, OCP --

Thanks Mark,

we are migrating a report system from the mainframe - each table represents one report type, with the columns representing meta-data of the reports themselves. each report has its own set of columns, although some reports coincidentally share the same set of columns, it's not set in stone going forward. my concern is that managing 23000 tables could be a nightmare - but i am actually not sure why! all efforts to consolidate more than one report into the same table eventually brings us to a situation where a table has 40-50 fields, but a particular report can have max 16 (limitation of old system) - so lots of NULLs - hence my question what is best.

We don't have the option to normalize our database as the new system works with a flat data model and cannot adapt to different model.

Thanks for your feedback! Chris. Received on Wed Nov 08 2006 - 18:20:06 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US