Re: gEDA-user: database driven component chooser - part II

[Dan McMahill <dan@xxxxxxxxxxxx>]

DJ Delorie wrote:
>> As the relation between 'device' and 'supplier' is a many-many
>> relationship, you'd be better off creating just another table,
> 
> I also recommend (and have been thinking about) a multi-table database.
> 
> One maps symbols to a symbol class (i.e. the N different ways to show
> a resistor), one maps classes to specific parts (manufacturer PN), one
> maps specific parts to vendors/prices/etc.
> 
> The first two are treated like one table (symbol->part) since you
> don't have a choice about the symbol class, it just "is".  Given some
> preferences, that's enough to get you to a pcb footprint.  The second
> table is used to complete the BOM, calculate pricing, and prepare an
> order.  Also, checking the second table lets you qualify entries in
> the first table; if you can't order it, don't pick it :-)
> 
> I suppose we could have footprint classes, too, to handle the
> "least/normal/most" suffixes we have for some parts.
> 
> Links:
> http://www.gedasymbols.org/csv.html
> http://archives.seul.org/geda/dev/Mar-2007/msg00180.html

At the risk of trying to make one giant perfect step which never happens 
as opposed to a moderate step in the right direction...  You may want to 
think about what it may take to be able to include netlist information 
for different backends.

In other words, it seems this database is oriented towards having 
netlisting for pcb Just Work.  If you want to work well with simulators, 
it may be of use to be able to specify how each heavy symbol will 
netlist for whatever simulator backend.  There is missing infrastructure 
in gnetlist and libgeda which would be needed, but it might not hurt 
keeping it in mind.

-Dan


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