Re: gEDA-user: Parts Manager Working Document

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Wed, 2010-01-27 at 15:18 -0800, Edward Hennessy wrote:
> --- On Wed, 1/27/10, Peter Clifton <pcjc2@xxxxxxxxx> 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@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user