Extending DataFinder to include Non-Data Entries and Relationships Between Entries

[Stocklone]

I am trying to create custom data centralization and management software for our lab with DataFinder Toolkit.  In addition to storing data from data acquisitions, I want to be able to store additional information with the data such as images, pdf files, word documents that can be easily accessed after finding the data.  My current idea is to handle external files by storing the filepath in a property of an object vs trying to store the data itself in the datafinder database.  My code would know how to open these files so the user can see them with external software or a custom labview app.

I also want to be able to store non-data objects such as an object that describes a piece of test equipment or a sample through properties and external files.  Images and documents are again important here.  And then create relationships through unique barcoded IDs that are a property in the datafinder entry.  So not only could I look at the data, I could find information about the samples and lab equipment. Or anything else we think needs to be saved.

The code I am writing around DataFinder would be in charge of maintaining the unique IDs and know how the relationships between those IDs work to generate the proper queries. Like a 'Get Test Equipment Used' button next to a search result.

For the external non-data objects I was going to use Labview code to create a file with all the information about the object (unique ID, properties and external file paths) and create a plug-in so the datafinder will index the file and make it searchable.

Does this seem reasonable? I like the idea of working with one system and having everything update based on adding, deleting and modifying files in a folder. Also, I like the idea of not splitting the data management up into multiple technologies and having to make those work together.

[LVbum42 · Accepted solution]

From the description, you've given the system seems plausible. The non-data elements you discussed when broken down are just additional data to associate with an object.  Storing file paths seems plausible as done in the community example below:

Execute String/Numeric Querry Using Data Finder Toolkit

https://decibel.ni.com/content/docs/DOC-10631

Regards,

Isaac S.