Re: using multiple subtables efficiently

> Table A holds general product information and the subtables hold > product-specific information.

Not enough information is given to suggest a clear solution, but having to join 8 tables in the above situation seems a bit much. Either you truely have a difficult design problem or the solution could be reworked.

An object-oriented database is especially appropriate with complex and variable data structures. For example in XDb, your data might be modeled as shown below, where "." indicates a property, [] indicates the ancestor class.

Product
.CommonProperty1 (ie. Cost)
.CommonProperty2 (ie. Price)

ProductA [Product]  (ie. Food Item)


 .Property1         (ie. Expiration)

 .Property2         (ie. FDA Approval)


 .Property3         (ie. Net Weight)



ProductB [Product]  (ie. Electonics Goods)


 .Property3         (ie. Warranty)


 .Property4         (ie. Service Plan)



ProductC [ProductB] (ie. Televisions, a sub of Electronic Goods)


 .Property5         (ie. Screen Size)


 .Property6         (ie. PixelCount)

Then you would make instances of the above classes. The class of any instances indicates its ProductType. An instance would have the properties of all its ancestor classes. Any instance can have fewer or more properties than described in its class. In addition, it is possible to model the properties in a class hierarchy that gives you power to ask object's generalized questions and get a specific answer. For example, if the properties NetWeight and ScreenSize are derived from a base property class called Size, then you can ask both a can of soup and a TV for their Size and get 12 oz and 27" respectively.

XDb yields highly normalized solutions with extreme flexibility.

XDb is an object-oriented database for Windows & Pocket PCs. Instantiate, reference, cut, copy, paste, delete, query objects via File Explorer like GUI. Fast, flexible, compact, orthogonal. Download your free copy (260 KB) from http://www.xdb1.com Received on Sun Oct 21 2001 - 06:23:47 CEST