I want to build a database that can be created via an ETL process from an existing spreadsheet based system which is the source of truth for the data...
Spreadsheets ----ETL----> Graph Database
... but I additionally want for some of my services that reference the Graph Database to be able to add 'Extra' data to the graph over time...
Other Service ----Extra info ----> Graph Database
...e.g. If there is a row in the spreadsheet that refers to a file, I would have a node in the Graph DB that represents the file and I might want another service to be able to update the DB to indicate that it has processed the file. It is not practical to simply add 'extra' properties onto the spreadsheet sourced nodes because the spreadsheet data is quite volatile and I would like to maintain the capability of completely tearing down and re-hydrating these nodes via the ETL at any time.
My first thought was to do something like this...
... where the File nodes are sourced from the spreadsheet are paired with File Metadata nodes that come from the service, with a 'Describes' relationship between them. the File nodes already have a unique key property which is present on the spreadsheets so that the File Metadata node can have a 'refers_to_key' property that would permit recreation of the relationship even if the File node is detach/deleted during a full ETL.
I guess the weakest part of the idea is the key/refers_to_key approach. Is there a smarter way to do this? Am I completely out of my mind?