Do I need a custom content type, entity, module or field? I'm working on a product information manager, and I have a content type of product which needs to reference stock and price levels for each supplier from a different database - these are stored as separate sqlite databases (one for each supplier) and managed outside of drupal.

I would like to reference the prices and stock levels without actually importing them all into the drupal database, instead pulling from the external database, but I'm a little confused how to structure this? One product can have many suppliers.

Do I need a separate entity to manage the pulling of the data (possibly one entity for each supplier) then somehow attach to the product node (manufacturer and part number would be used to search the supplier db), or, would it be considered a field, or a module with options set specifying the database location for each content type. Each product node shouldn't have to specify its list of suppliers.

The data would need to be shown when a node is displayed - I would like the data to be accessible from within views, but also searchable, e.g. display products where stock level &lt; 3 for supplier xyz.

I'm thinking an entity wouldn't be correct as an input of manufacturer and part number would be needed before the data can be pulled?
The data would need to be shown when a node is displayed - I would like the data to be accessible from within views, but also searchable, e.g. display products where stock level &lt; 3 for supplier xyz.


How can you say I want the data to be integrated into my website -- but not imported into Drupal. Your goal sounds like alot of work.

You could try something like Remote Entity. But honestly I would take some time to learn the Migrate module and use Rabbit Hole to insert the data as "hidden" data to drupal entities or content types in my site. Migrate is super powerful for this type of syncing of data (syncing being a topic I think you're glossing over).

EDIT

You could try to:


use hook_entity_view_alter to put content into a node view.
use hook hook_views_data and putting your DBs into settings.php to be useable by Views displays and filters.
use something like hook_search_api_query_alter to include your custom dbs in queries to search


... all of these in my opinion would be harder to maintain in the long run, rather than a recurring interval of updates or syncing of data using Feeds, Migrate, and storing a copy of the data locally in a drupal friendly format (eg a content type or entity).