I'm using a DBLib, and really like it. It's basically just me doing the electronics design here, though, so not sure how well it would translate to a larger shop. The way it works is you create SchLibs and PcbLibs separately, typically with a bare minimum of information, and then use a database to link schematic symbols to PCB footprints and define whatever other paramaters (even supplier links) you want. The big advantage is that it's incredibly easy to create a symbol or footprint ONCE and then reuse it as many times as you want.
I'm using Access for the underlying DB, but you could use any number of database solutions, or even Excel. I have a separate table for different classes of components--resistors, capacitors, inductors, ICs, diodes, transistors, connectors, board features (pads, SMD jumpers, etc). This way each table can have columns specific to each type--power rating for resistors, ripple current for caps, etc--without adding dozens of extraneous parameters to every single part. In the dblib configuration you can specify which columns are added and how they map to parameters. Every table has "type", "subtype", and "subtype2" columns which are used for high level filtering, which works better in the library browser if you filter on the same columns in every table. Speaking of the library browser, it's very fast with DBLibs even with large numbers of components.
The database format makes it very easy to move data into and out of the library. So for instance, I got really lazy with descriptions for a while, so rather than manually type in dozens of descriptions, I just copied a table into Excel, used a formula to concatenate some key fields into a useful description, and then pasted it straight back into Access. If you were really keen, you could of course create forms that interact with your database and create such things automatically on insertion of a new component. Somebody actually sells and Access front end that allows you to drag a link from a supplier into a form and automatically scrapes the component information into the database, though I don't remember what it's called at the moment. You could also theoretically use the database to connect your Altium library to your ERP system.
There are a few bugs to watch out for, though (as of 15.0.14):
- If you link on a column that is not unique across your database (for instance a simple autonumber column unique in each table), the library browser can get confused and display information from the wrong table. The workaround is to link on two columns to assure that each component gets a Design Item ID that is unique across the whole database. My method is to have an autonumber ID column and a column that identifies the table, and link on both. If your company has internal part numbers that are unique, you could use that on its own.
- Having a parameter named "table" (for instance as part of the previously described workaround) can cause BOM generation to fail. So name that column something else!
- Using the table browser in the DBLib setup to edit the database can overwrite entire rows with data from other rows, so just don't use it. Unfortunately this eliminates a convenient way of adding supplier links, but it's not hard to do that in the database directly.
All in all, even with the bugs, DBLibs are really great, and as a small shop I pretty much wouldn't do it any other way. The one thing that's a bit of a pain is components that have standard symbols and standard packages but non-standard footprints, like oddball transistors and such, since there's no way to abstract the mapping of schematic pin to PCB pad. So those require special treatment, but in that respect it's no worse than a conventional integrated library.