Re: gEDA-user: symbol databases, was Re: Wish list, sort of

[Mike Crowe <mcrowe@xxxxxxxxxxxxxxxxxx>]

On Tue, 2009-01-06 at 20:36 +0000, Kai-Martin Knaak wrote:
> On Tue, 06 Jan 2009 07:26:08 -0500, Dave McGuire wrote:
> 
> > But database servers, MySQL servers
> > in particular, are pretty ubiquitous, and the API is easy.
> 
> No doubt, a data base can be fine and powerful. However, many tasks have 
> to be implemented by the application. From the top of my head:
> searching, editing, versioning,	back-up, character encoding, permissions, 
> import/export, updates, ...
> 
> Failure to do these tasks properly would cripple the user experience. A 
> directory based approach can refer the user to the general tools of the 
> OS. No need to spend valuable developer resources on this kind of 
> infrastructure.  
I agree that adding a database adds end user complexity that should
probably be avoided.  I also agree that there are limited developer
resources available, but a new optional interface, largely worked on by
new developers would address these concerns.

I have used some of the comercial schematic packages that allow
integration of attribute information into a database.  It provides
significant improvements for tasks such as; generating purchasing
requests, inventory management, and bill of materials management, and
component obsolescence.  When viewing the attributes on the schematic,
one is looking at the latest component information.

Our company uses an internal part number.  In the parts database, there
is:
	an inventory table providing part number -> location, quantity keying
	bill of material table providing build number -> part number keying
	component table providing part number keying -> general attribute
information
	vendor table providing vendor -> part nubmer keying.

>From these tables we generate 
	Build shortages
	Bills of materials
	Purchase requests

At this point, I use gschem to create a crappy bill of material which I
import into the database.  The schematic becomes depricated over time
because the attribute info in it does not update as the database is
updated.  

My personal desire is to allow some way of maintaining the attributes
through the database, while leaving the graphics and netlist alone as
after a board is designed those aspects become pretty much static.  If I
can do this with gschem then the schematic remains a viable tool.

By the way, I also use external version control to maintain schematics
(subversion).  Works well.

They way the development environment is shaking out it appears that
adding the back-end tools to do these things is pretty straight forward.
(Thanks for the links Werner)

> 
> ---<(kaimartin)>---



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