Further thoughts on the "libraries in databases" topic: Assuming that KiCAD included a database like SQLite, the master database of all parts could be stored on the web somewhere and each project could have a local database of only the parts that it uses (a small subset of the master database).
Every entry in the master database would have a version stamp, and versions would never be deleted, so changes or bug fixes would not cause old designs to break. It would no longer be necessary to download the entire library when getting an updated version of KiCAD. If you trust your web connection, you could just hook up to the master library via the web; the only traffic in normal use would be search queries to the master database and the occasional download of the specific part that you choose. If you require the ability to work offline, you could maintain a private cached copy of the master database, and from time to time you could update that by pulling down records that are newer than your last sync point. The key to making that work is the "nothing is ever deleted" property. A version control system like Subversion has some of the necessary capabilities, but I would argue that an SQL database would be better. Version control systems impose a structure that is tuned toward hierarchical software source trees, and usually lack the ability to search for objects based on flexible criteria. For large CAD libraries, it's important to have a rich set of metadata so you can find parts. The problem with rigidly structured hierarchies is that there are several plausible ways to organize them. Different people will slice the space in different ways. With a database, you would not need a hierarchy at all. Each part could have a list of attributes, and you could search on any combination of them. The metadata might include: General categories (connector, opamp, resistor, DSP, processor, codec) Package type Manufacturer Family (e.g. the "Virtex-4" family from Xilinx) Alternate part numbers (second sources, suffixes, etc) Number of pins Documentation links Power requirements (voltages, power) Supplier info (e.g. stock numbers from popular distributors) Mitch Bradley wrote: > > On the topic of library organization: > > It occurs to me that CAD libraries really should be stored in SQL > databases. Traditional library formats tend to impose an artificial > structure that is too rigid. Using a database would make it easier to > handle real-world problems such as multiple versions of the same part, > providing flexible searching, revision control, etc. Most web hosting > services offer a database (e.g. MySQL) as part of the deal. It would > even be possible to embed a database within KiCAD (e.g. SQLite - > http://www.sqlite.org/ <http://www.sqlite.org/> ). > > Mitch Bradley > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Yahoo! Groups gets a make over. See the new email design. http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/W4wwlB/TM --------------------------------------------------------------------~-> Please read the Kicad FAQ in the group files section before posting your question. Please post your bug reports here. They will be picked up by the creator of Kicad. Please contribute your symbols/modules to the library folder in the group files section. For building Kicad from source and other development questions visit the kicad-devel group at http://groups.yahoo.com/group/kicad-devel Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/kicad-users/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
