Re: gEDA-user: Parts DB

[Dave N6NZ <n6nz@xxxxxxxx>]

Peter Clifton wrote:
>> 
> One thing I thought of whilst reading this.. is that an "attributes"
> table, to store attribute meta-data which will make it into gschem.
> "SELECT * FROM attributes WHERE partnum = xxxxx;" might give you the
> attribute results:
> 
> name      | value
> ----------+----------
> refdes    | foo
> value     | bar
> model     | ......
> 
> etc..
> 
> I still see refdes as kindof special, but allowing this sort of table
> will let you attach any useful netlistable attributes right into the
> data-base.
> 
> I notice "symbol" is missing from your fields, and with this addition,
> you might be able to place "parts" down directly in gschem if you
> wanted.

Sure.  My parts database was started to solve the traditional problem of 
BOM and inventory management.  The discussion meandered over here from 
the heavy/light symbols debate, and there is nothing in my original 
design that addresses schematic integration other than being able to get 
a footprint from a part number.

As I mentioned in a previous thread, I have worked with schematic 
systems where it worked pretty much like you suggest.  The schematic 
editor in that case was really only a specialized viewer/editor on a 
relational database, although very few of the users understood the 
machinery behind it. (It was well done!)  There were clear benefits to 
that architecture.

> 
> Would you like A database GUI component chooser in gschem etc.. which
> _only_ lets you pick from the database? 

Ack!!! You mean forcing myself do be organized and have my parts 
database up to snuff before whacking out a schematic?  Being systematic 
and consistent and all that?  You want to take away all the fun :)

Actually, it would be very nice if there were a way to integrate a the 
component chooser dialog so that the option existed to pick up part 
number and and footprint (and other attributes) from a database.

 > I imagine this being available
> as a "plugin" tab in the component selector, backed by a user-defined
> application.
> 
> You could already do it with user-defined guile / script backed
> component sources.
> 
That would be very interesting.  I would use that.  It would save work 
and encourage me to keep my parts database up to date.

One thing I neglected to mention in my earlier post is the concept of 
revision management, which is an important part of any design automation 
database. In my database, I handle it in the part number.  The database 
is intentionally light weight w.r.t. revision management. The table 
descriptions show only "varchar(20)" for part numbers, but I have 
certain conventions for part numbers. My scheme is:
CCCC-XXXXX-RR for revision controlled things
and
CCCC-XXXXX-pppp for simple components w/o revision control

Where CCCC is a 4 digit class number
XXXXX is a unique identifier
RR is a revision
pppp is a package (typically)

So, for a revision controlled PCB:
03xx -- it's a pcb
0301 -- pcb of a particular modular form factor
0301-00101 -- uniquely identified PCB design
0301-00101-A0 -- first revision

Revision could as well be another column every where a part number 
appears, but it makes the SQL messier for questionable benefit, and 
since this was supposed to be a "tiny database just for me" I went with 
a simpler solution.

-dave


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