Christoph Lechner <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Levente wrote: >> Duncan Drennan <[EMAIL PROTECTED]> wrote: >>>> I'm back from Stuttgart where I could hack a bit on my database stuff. >>>> Now, I have a command line SQL client, which can be used as a chooser. It >>>> takes command line arguments as search parameters, and makes an SQL query, >>>> and >>>> prints the result. >>> Levente, where could I find out more about what exactly your programme does? >> >> I am about to write a README for it, and check it into my CVS repository, but >> my washingmachine died, so I have to go to my parents to do the whashing. >> >> But in a nutshell, it looks up a component from a mySQL database, and >> parse the result. The database is online, and so you can see what is >> inside. > OK. I took a look at the database. So a question came to mind when I saw > the layout of the 'device' table: > Why do you store the relationship between entries in the 'device' table > and entries in the 'supplier' table in fields named supplier*, > ordering_code*, price* in the 'device' table? What if there are more > than 3 suppliers for any given part? > > As the relation between 'device' and 'supplier' is a many-many > relationship, you'd be better off creating just another table, holding > the device's ID, the ID of the supplier and fields for the ordering_code > and the price. Then you only need to LEFT JOIN the tables > rel-device-supplier and supplier and you get all suppliers for a given > part. This would give you a somewhat tidier DB layout ...
This is a good point, and my client code doesn't need so much tweek to implement this. I think it doesn't need any, hence it is a component chooser. But sure this method gives much more flexibility on the supplier business. Thank you very much for your comment! -- Levente http://web.interware.hu/lekovacs _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
