On Wed, 2010-01-27 at 15:18 -0800, Edward Hennessy wrote: > --- On Wed, 1/27/10, Peter Clifton <pc...@cam.ac.uk> wrote: > > > Good database design dictates that the device types are not > > hard-coded > > into the data-structure, there is no explicit "resistors" > > table JOIN'd > > to drag in resistor specific data etc.. > > There really isn't a good solution for relational databases. > This article summarizes the trade-offs well: > > http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/
I was more thinking along these lines.. Rather than having a component "class", explicitly subclassed in the database to contain resistor specific attributes, I would do it similar to the following: 1 "component class" / table, one size fits all. Each has a component ID. 1 "attribute type class" / table, one size fits all (?) An entry might be: Attr_id 213 Attr_name "tolerance" Attr_legal_values percentage .... Attr_id 214 Attr_name "stock_level" Attr_legal_values integer .... And there would be some table which mapped components and their attributes. Component_id 123123123 Component_name "foo" <------ Ok, this could be a mandatory attribute, but that is getting crazy! And the mapping: Component_id 123123123 Attr_id 213 Attr_value 0.1% .... Component_id 123123123 Attr_id 214 Attr_value 100 .... In this respect, you're using the database as a kind of "meta-database", where the real mapping between objects and their attributes exists within a limited number of tables. OTOH, someone can probably tell me why this is "BAD^(TM)", and how modern databases can support ad-hock addition of specialised tables and / or fields to the existing database structure. One could also envisage tables with guides to creating component classes. Component_class_id 1 Component_class_name "Generic physical component" Component_class_parent_id NULL Component_class_id 37 Component_class_name "Resistor" Component_class_parent_id 1 Component_class_id 1 Component_class_attr_id 214 Component_class_attr_rule "Optional" ... Component_class_id 37 Component_class_attr_id 213 Component_class_attr_rule "Mandatory" Anyway.. I should be working.. and I'm not. Back to it! Best wishes, Peter C. > PostgreSQL operates as both a relational and object database, > so an implementation in PostgreSQL would be much cleaner. > > I believe the options include a single table for part, or > using multiple tables for part. There are advantages and > disadvantages for either. From previous experience, I'm > in the multi-table camp. The mailing lists seem to be > gravitating to the single table implementation for reasons > of simplicity. > > I'd like to point out that the database implementation uses > views to provide logical data independence. So, the user > and applications would be relatively immune to the underlying > database structure. So, supporting both single and multiple > tables at the user's option could be done also. > > The git repository contains some of the SQL code to get the > multi-table database up and running. The sample code > probably describes the database structure better than my > working document. > > Cheers, > Ed > > > > _______________________________________________ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user