Levente wrote: > Bill Gatliff wrote: > [...] > >> Gosh, I think it almost does. You have a footprint column in your >> device table, and it seems as though only one footprint would apply to a >> specific device--- an 0603 resistor is always going to use the 0603 >> footprint. So if you had resistors with other footprints, they'd be >> different entries in the table, right? >> > > Right. Wrong! What about a TO220 transistor? You have standing and > laying version, I do have an SMD version too. You may have a footprint > for other technologies of soldering... such as reflow, wave, etc. You > may have different resist opening version... etc. I think it might be a > good idea to have a separate footprint table for footprint variants. >
I think we're in violent agreement, but might be talking about subtly separate things. A given device e.g. a particular transistor may be available in one or more specific physical _packages_, i.e. TO220, DPAK, etc. If you had a collection of such devices in different packages, then they'd be different part numbers--- but you'd probably capture the basic name of the transistor device in the description fields of your database i.e. "2N7002", "n-channel", "transistor" so you could later ask for "a transistor in a TO200 package, any vendor". You'd have two or more rows with that same description (hence the need for a description convention), each of which differed only by the package and part number for the device(s) you bought. There are several PCB layout _footprints_ that are compatible with a TO220 _package_, but that's information that's tied to a specific part number only through what package the device referred to by that part number came in. PCB doesn't care that it's a 2N7002, or even that it's in a TO220 package--- it just wants to know what footprint you want, and you want to make sure that the footprint that you tell it to use will actually work with the package the physical device came in. So your device table needs a package field, which reflects the actual physical package the device came to you in. Then you need another table that maps package types to compatible layout footprints. Then you select from that list of footprints based on the characteristics of your circuit board. (Actually, since Fairchild has their own naming conventions for packages, which will be different names but the same physical characteristics as those offered by other vendors, you might want the schema to be slightly more complicated than the above. You could even have a schema that fills in some of the package and other information for you based on the header and footer of the part number. But I digress). >> I don't think you are using your schema very effectively, however. I >> think your description field should at most contain the word "resistor", >> since you are capturing things like footprint and value in other fields. >> > > That is why I have the category and subcategory tables. > Yup. But I'd give them more specific names, so that you don't miss a search because the "resistor" was in a field other than the one you searched in, perhaps due to an entry error. It's a taxonomy thing. > Well well. This system is still a "quick and dirty hack"... :-) What you > can do is a query for category=1, subcategory=1, value=10R. That is what > I do day by day. However, you are probably right. This is my first SQL > database, and one may see that I don't have experience with it. :-) > Me neither. I've done only two or three myself, but I've looked over a lot of shoulders and had to deal with a lot of databases that weren't set up to my liking. :) > The next step with this system is to write some (G)UI for those tables. > I usually use the phpmyadmin interface. It is OK, but could be better. > Or even better... integrate it in gschem. > Gschem and PCB could both incorporate sqlite, and then we could set up a community database somewhere that as we bought parts we could enter the part numbers/packages information into. And then as we created footprints, we could put those into another database. Then later on, when I had a particular part number (perhaps from a device=) then a tool could show me a list of compatible, predefined footprints. Kind of like a next-generation version of what gedasymbols already is. Or could be. > Any volunteers? :-) > Not me! I'm more of an "idea guy", especially when it comes to databases. :) I would be happy to supply the IP address, however. b.g. -- Bill Gatliff [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
