kicad-developers team mailing list archive

["dioiioib" <dioiioib@...>]

--- In kicad-devel@xxxxxxxxxxxxxxx, Manveru <manveru@...> wrote:
>
> 2009/7/8 dioiioib <dioiioib@...>:
> >
> >
> >
> >> to create their own database with parts. Local database could be hold
> >> as SQLite, but we should keep file format as transfer files for users
> >> wanting to share their new parts without repositories. This system
> >> should be transparent for beginners with KiCad and should allow
> >> advanced configuration only on demand.
> >
> > What it seems like people are saying, is there is a lack of a good archive
> > website. If the parts are to remain readable plain text, which I am in favor
> > of, shouldn't someone just commit to setting up a decent website with an
> > archive, which would most likely include a database.
> >
> > The current system works quite well for me, although if the intention is to
> > include SPICE or other simulation data we might need a database to keep
> > track of all the parts, but again a website would be the most simple
> > solution.
> >
> 
> I am thinking about such service, but have no time to implement stubs
> showing some of functionalities. I would like to have a parts review
> with suggested module packaging and advanced search criteria. The
> problem is that different types of parts have different types of
> important criteria what creates multidimensional relations between
> data and I never do such database.
> 
> -- 

I agree. The problem with any database SQL, Access, or otherwise is that the initial design needs to be close to perfect for it to work. What I mean by this is your planning must address all needs and future needs before implementation or you end up doing more work to correct your problems or even worse redesigning the database. Because Kicad's feature set is still growingintegration into kicad for this type of database may-not be the best solution. I would be more than willing to work with you Manveru, to create an external database, that could search out specific criteria for parts in both the lib and mod files. 

What criteria specifically are you interested in referencing for the relationships between tables? The other issue that must be dealt with is how to make ID Keys for each part. 

I do see other issues with implementing this database, which were mentionedearlier in this same thread and have personally bothered me too. There is no standard implementation for PIN types as of this time for kicad parts. Most of the existing parts use the same "INPUT" style pin for everything, with exceptions often found in 4000 logic and some 74** type chips. Before anything like this is even attempted issues such as this need to be address, as searching a DB base on pins could be equally useful, as chip name / markings, size / type (IE. SOIC, TQFP, ...), number of pins, etc. Especially when reverse engineering poorly made schematics.