--- On Wed, 1/27/10, Peter Clifton <pc...@cam.ac.uk> wrote: > Good database design dictates that the device types are not > hard-coded > into the data-structure, there is no explicit "resistors" > table JOIN'd > to drag in resistor specific data etc..
There really isn't a good solution for relational databases. This article summarizes the trade-offs well: http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ PostgreSQL operates as both a relational and object database, so an implementation in PostgreSQL would be much cleaner. I believe the options include a single table for part, or using multiple tables for part. There are advantages and disadvantages for either. From previous experience, I'm in the multi-table camp. The mailing lists seem to be gravitating to the single table implementation for reasons of simplicity. I'd like to point out that the database implementation uses views to provide logical data independence. So, the user and applications would be relatively immune to the underlying database structure. So, supporting both single and multiple tables at the user's option could be done also. The git repository contains some of the SQL code to get the multi-table database up and running. The sample code probably describes the database structure better than my working document. Cheers, Ed _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user