Armin Faltl wrote: > since the stuff I managed to layout with your help is soldered now and > shining brightly, > I got some time, to have a look at my attempt to a database. So I have > to take levels > of abstraction and their naming serious.
I'd avoid data base solutions for footprints, symbols, simulation models and the like. * Unless there are excellent import/export functions, a data base is an additional obstacle to collaboration. These functions need to be written and maintained- * Only a very small subset of the operations available on file systems is present by default in data bases. Just to get the same level of user power as with files, a major effort of data base scripting is needed. * A data base can easily be corrupted on update of the data base driver. * Open source data base drivers like postgres or mysql may be quite mature. Compared to the stability of the unix file utils they still look shaky. And fast moving. * A data base would add a major dependency to the already significant set. * The number of all objects in the library is fairly moderate. All symbols and footprints from the distribution plus all of gedasymbols are currently about 4300. This can easily be handled by a file system. Just my two euro cents. ---<)kaimartin(>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user