Author Topic: DBLib with individual tables for each component type: Thoughts?  (Read 187 times)

0 Members and 1 Guest are viewing this topic.

Offline twistedresistor

  • Contributor
  • Posts: 37
  • Country: 00
DBLib with individual tables for each component type: Thoughts?
« on: October 09, 2019, 07:04:43 am »

just wanted to hear your opinion on library organization. I'm debating using separate tables for each component type e.g. diodes, resistors, capacitors, transistors with their respecting parameters.
Basically what DigiKey does.

Right now I have one table with all components. Using fields Voltage, Current, Power, Tolerance, TempCo. This makes sense for most of the components.
The big advantage to this is, that I can display this few parameters on the BOM which allows to find alternate parts, or quickly verify the properties of the component in case the MPN is non-descriptive.

Using a individual parameter set for each type of component would allow to store more specific information, but also blow up the BOM exponentially.

What are you guys thinking? Also where do you draw the line: do you stop at IC or do you use seperate tables for opamps, ADCs, MCUs?

Offline ddavidebor

  • Super Contributor
  • ***
  • Posts: 1135
  • Country: it
    • Fermium LABS website
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #1 on: October 09, 2019, 12:36:09 pm »
It will not help you in BOM organization, the BOM columns are fixed for each project, you cannot change them depending on your table columns.

Davide Bortolami,
Fermium LABS srl

Offline nickb

  • Contributor
  • Posts: 7
  • Country: be
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #2 on: October 09, 2019, 02:02:16 pm »
I'm using an excel file as my database (hope to switch to sql at some point) and have split up the lib in component types with their specific parameters.
In Altium it looks like separate libraries, it's probably a personal taste but I like it this way, allows for some filtering when looking for a specific component.

Offline Gribo

  • Frequent Contributor
  • **
  • Posts: 410
  • Country: ca
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #3 on: October 11, 2019, 04:18:53 pm »
My DB is setup with multiple tables, one per component type, however, the BOM includes only the minimum required parameters to manufacture the board (RefDes, PN, supplier, footprint etc.)
The electrical parameters appear as a single string in the description column. This way, the BOM stays neat, and most of the information is included.

Offline ajb

  • Super Contributor
  • ***
  • Posts: 1679
  • Country: us
Re: DBLib with individual tables for each component type: Thoughts?
« Reply #4 on: October 11, 2019, 04:41:54 pm »
I'm going to lazily copy and paste what I've said previously on the topic, but the TL;DR is that in my opinion putting a whole bunch of parameters into your dblib is a waste of time, and if you're not doing that then there's no point in having separate tables per component type. 

There's also a temptation to do a separate table for each part category, and put in a whole bunch of different parameters so that you can select parts parametrically when inserting parts into a design, but IME that's a huge waste of time.  I mostly just put the headline specs in the description for the part, and if I need more detail than that I have a link to the datasheet just a right click away.  Stuff that is critical to selecting a part on a basic level goes into the hierarchical type/subtype fields, so for instance I have Caps->MLCC and then dielectric is a subtype of that, so I can easily put C0G parts where I need them and cheaper dielectrics where I don't.

Even if it's quick and simple to do, both database design mentalities (super table with tons of empty columns, or tons of tables) kind of make it a royal pain. Most dblib users end up settling for a very minimal set of attributes because of that, which to me sounds like a bad compromise.
  How many attributes do you really need to keep in the library anyway?  Anything less than transcribing the entire datasheet into parameters is going to be some sort of compromise, and it's not like you can stick an operating curve into a parameter, and those can be quite important in evaluating a part's suitability.  Even if you do transcribe every single parameter, you can't always directly compare these between different parts because they may be specified under different conditions--so it's back to the datasheet anyway.  I won't tell you what works best for you, but personally I've come to the conclusion that putting anything beyond headline specifications into the library is not a good use of time no matter what sort of library you use.  When the basic specs aren't enough, that's why you have a link to the datasheet in the library.

I'll agree that Altium's dblib management tools are bad enough to not even be worth mentioning, I too have been meaning to create a DB front end (hasn't everyone?), but I just do everything in Access and don't find it appreciably more difficult or tedious than any other method of library creation.  The file paths are annoying, but for basic things like resistors it's mostly a matter of copying and pasting a row and editing a couple of fields.  For anything else it's not much more work, really, because I don't bother with more than a couple of key parameters.

If you just want hierarchical organization of components, you can do that by having hierarchical category fields and using those to sort in the library browser:


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo