DBlib - suggested columns for mysql table - Page 1
Forum section: electronics / general

author: zarthcode
author_rank: Newbie
timestamp: July 14, 2021, 05:10:56 am
content: 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?

author: zarthcode
author_rank: Newbie
timestamp: July 15, 2021, 08:42:12 pm
content: For anyone else who finds this while going down this road, AP0133http://valhalla.altium.com/Learning-Guides/AP0133%20Using%20Components%20Directly%20from%20Your%20Company%20Database.pdfon 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:Part NameDescription → Footprint Ref → [Footprint Ref]Footprint Path → [Footprint Path]FootprintDescription1PackageDescriptionLibrary 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]StatusAuthorCreateDateLatestRevisionDateManufacturerManufacturer Part NumberCommentComponent KindComponent TypeFolderMounting TechnologyHelpURLComponentLink1URLComponentLink1DescriptionDatasheet URLFootprint Ref n → [Footprint Ref n]Footprint Path n → [Footprint Path n]FootprintName2FootprintRevisionID1Pin CountCaseDeviceComponentHeightComponentWidthManufacturer1 ExampleManufacturer1 Part NumberManufacturer1 ComponentHeightComponentLink2URLComponentLink2DescriptionDatasheet VersionResistanceCapacitanceValueTCPowerToleranceVoltageStorage CellStorage QuantityI 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?)

author: ajb
author_rank: Super Contributor
timestamp: July 16, 2021, 07:45:22 pm
content: 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.