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