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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
