DBlib - suggested columns for mysql table

[zarthcode]

I'm asking just what the topic says... I'm implementing a svndblib, and would like to know what columns have you all used in your DBlib backend?  I don't really want/need to search by everything - but is there an upside to making component-type-specific tables for resistors/caps/discretes so they are more searchable?  Is there a master list/documentation of the different component parameters used?

[zarthcode]

For anyone else who finds this while going down this road, AP0133 http://valhalla.altium.com/Learning-Guides/AP0133%20Using%20Components%20Directly%20from%20Your%20Company%20Database.pdf on Altium's site does list a few parameters (some since deprecated).  Here are those, plus a few other "known" parameters you might find interesting.

Code: [Select]

Part Name
Description → [Description] 
Footprint Ref → [Footprint Ref] 
Footprint Path → [Footprint Path]
FootprintDescription1
PackageDescription
Library Ref → [Library Ref] 
Library Path → [Library Path] 
Sim Description → [Sim Description]
Sim Excluded Parts → [Sim Excluded Parts]
Sim File → [Sim File]
Sim Kind → [Sim Kind] 
Sim Model Name → [Sim Model Name] 
Sim Netlist → [Sim Netlist]
Sim Parameters → [Sim Parameters]
Sim Port Map → [Sim Port Map]
Sim Spice Prefix → [Sim Spice Prefix]
Sim SubKind → [Sim SubKind]
Status
Author
CreateDate
LatestRevisionDate
Manufacturer
Manufacturer Part Number
Comment
Component Kind
Component Type
Folder
Mounting Technology
HelpURL
ComponentLink1URL
ComponentLink1Description
Datasheet URL
Footprint Ref n → [Footprint Ref n] 
Footprint Path n → [Footprint Path n] 
FootprintName2
FootprintRevisionID1
Pin Count
Case
Device
ComponentHeight
ComponentWidth
Manufacturer1 Example
Manufacturer1 Part Number
Manufacturer1 ComponentHeight
ComponentLink2URL
ComponentLink2Description
Datasheet Version
Resistance
Capacitance
Value
TC
Power
Tolerance
Voltage
Storage Cell
Storage Quantity

I wouldn't suggest using all of those. I managed to whittle down my needs to *just* 41 columns (including a UUID/Part number).  Now, I have a git-repo+db that functions a bit like a vault, can pull data from octopart/digikey/newark, and will be a breeze to integrate w/my ERP.  And it isn't $1000+/yr/seat for basically a cloud-hosted git+vault - it just runs on a docker container on a local server pc and does a cloud backup every now and again. 

But really, by right, Altium should have 1st-party database support, already - and there should be a "gitdblib" format, too. While they aren't actively stripping ODBC - they would rather sell 365 than fix it. (Also, what happened to the Git provider that never actually worked?)

[ajb]

There have been a few threads here on the design of backing databases for Altium libs, if you search for "dblib" here you should turn up a few.  I've given my opinion in a couple of those, but in general, I wouldn't recommend doing separate tables for different part types, nor trying to capture a whole lot of component specifications in the database.  Just put the headline specs in the description field, the value in the value field (and you can set the comment parameter in your symbols to "=Value" to make it show up there--great for passives especially), and include a link to the datasheet for when you need to dig deeper into the specs.  Trying to incorporate a whole lot of performance specs as database parameters is a waste of time IMO.  Having things like MLCC dieletric type or resistor precision/tempco as parameters can be nice, I have symbols defined that will show those on the schematic which is handy.  My default resistor symbol only shows the resistance, but I have an alternate graphic mode that shows the tempco and precision for those places where it matters to the circuitry.

For organization, I included a four-level set of hierarchical fields, which you can use to group things in the component browser.  These are pretty freeform and have grown a bit inconsistent after using this library for a few years, but in general it makes it pretty easy to find what I need.  You can of course use more or fewer levels depending on how granular you want to get, but I find four (where the top level is the component type) works well for me.